Support fully qualified table names in all statement types

[JanJakes]

This PR:

1. Adds support for fully qualified table names (like wp.my_table) for all statement types (they weren't supported before):

   CREATE TABLE wp.t ...;
   DROP TABLE wp.t;
   INSERT INTO wp.t (id) ...;
   SELECT * FROM wp.t;
   UPDATE wp.t SET ...;
   DELETE FROM wp.t;
   TRUNCATE TABLE wp.t;
   SHOW CREATE TABLE wp.t;
   SHOW COLUMNS FROM wp.t;
   SHOW COLUMNS FROM t FROM wp;
   SHOW INDEXES FROM wp.t;
   SHOW INDEXES FROM t FROM wp;
   DESCRIBE wp.t;
   SHOW COLUMNS FROM wp.t;
   SHOW INDEXES FROM wp.t;
   SHOW INDEXES FROM wp.t;
   LOCK TABLES wp.t READ;
   ANALYZE TABLE wp.t;
   CHECK TABLE wp.t;
   OPTIMIZE TABLE wp.t;
   REPAIR TABLE wp.t;

2. Enables read usage of information schema tables in write queries:

   INSERT INTO t (id, value) SELECT 1, table_name FROM information_schema.tables;
   INSERT INTO t (id, value) SELECT 2, table_name FROM (SELECT table_name FROM information_schema.tables);
   INSERT INTO t (id, value)
       SELECT 3, it.table_name
       FROM information_schema.schemata s
       JOIN information_schema.tables it ON s.schema_name = it.table_schema;
   DELETE t FROM t JOIN information_schema.tables it ON t.value = it.table_name;

Point 1 is needed for phpMyAdmin support, and point 2 naturally emerges from implementing 1.

[adamziel]

Fixes the usage of fully qualified table names (like wp.my_table) for all statement types like:

I'll probably learn that in a minute after reading the code, but at the moment I'm confused what does "fixing" mean, as in what's broken and what's different with this PR. Let's spell it out explicitly for when we browse the commit log in the future.

[adamziel]

			array( 'REPLACE INTOtables (table_name) VALUES ("t")' ),

Is INTOtables intentional? If not, should we be worried that the tests pass?

[JanJakes]

@adamziel Oh, thanks for catching this! We should be worried indeed; seems like the lexer doesn't require the space in this case, but in MySQL, it should fail: https://onecompiler.com/mysql/442dtf2yu

I will create a ticket for this.

[JanJakes]

@adamziel Ah, no, all good, the INTO keyword is optional, so it parses INTOtables as an identifier (= table name), but since it targets the information schema, the correct exception is thrown.

The grammar:

REPLACE_SYMBOL (LOW_PRIORITY_SYMBOL | DELAYED_SYMBOL)? INTO_SYMBOL? ...

[adamziel]

Oh wow, TIL

[adamziel]

I'm still lost. Does it allow us to still use the fully-qualified table names, e.g. wp.wp_posts after the database name changes from wp to, say, migrated_site?

[JanJakes]

I'm still lost. Does it allow us to still use the fully-qualified table names, e.g. wp.wp_posts after the database name changes from wp to, say, migrated_site?

@adamziel Oh, sorry for not explaining this better in the description. This ensures and tests support for the db.table syntax for scenarios like this:

USE information_schema;
SELECT * FROM tables; -- this targets information_schema.tables;
SELECT * FROM wp.wp_posts; -- this was not working for many statement types before
CREATE TABLE wp.new_table ...; -- phpMyAdmin does exactly this
-- etc.

USE wp;
SELECT * FROM infromation_schema.tables; -- this was already working

[JanJakes]

@adamziel I rebased this to resolve conflicts.

[adamziel]

Lovely! Perhaps the corner case won't ever come up 🤞

[adamziel]

LGTM, thank you!