only rewrite database() against dual

[deepthi]

When we implemented handling of database() to map to keyspace_name, we didn't consider cases where the expression is part of a query that is being sent to a tablet instead of being handled in vtgate.

So a query like select database() would return the keyspace name (which is correct), but a query like select table_name from information_schema.tables where table_schema = database() would not work as expected because the table_schema doesn't match the keyspace name.

This is a stopgap fix until we fully implement information_schema.

Adapted from #5787 with unit test fixes and more tests.
cc @systay

[systay]

@deepthi, You are correctly pointing out inconsistencies with the illusion we are creating when doing this query rewriting. The way I see it, we have a few choices:

1. Don't rewrite database() calls. This is what we did before, and the inconsistency was that USE and database() become disconnected from each other:

mysql> use test;
Database changed
mysql> select database();
+------------+
| database() |
+------------+
| vt_test    |
+------------+
1 row in set (0.00 sec)

2. Rewrite all database() uses. One of the inconsistencies introduced is the mismatch with the information in information_schema.

3. Try to be clever and rewrite when we think that makes sense. This PR rewrites all queries where the query is a SELECT either without a FROM clause, or one with only dual in it. The thinking is that if the query is SELECT database() or something like that, we use the keyspace name. But if you pull in data from any other source than dual, we'll not handle it by rewriting and lean on mysqld to evaluate it for us.

Another heuristic we could use is to only rewrite database() in SELECT projections, but not in WHERE predicates.

Input is most welcome.

[deepthi]

@deepthi, You are correctly pointing out inconsistencies with the illusion we are creating when doing this query rewriting. The way I see it, we have a few choices:

1. Don't rewrite database() calls. This is what we did before, and the inconsistency was that USE and database() become disconnected from each other:

mysql> use test;
Database changed
mysql> select database();
+------------+
| database() |
+------------+
| vt_test    |
+------------+
1 row in set (0.00 sec)

1. Rewrite all database() uses. One of the inconsistencies introduced is the mismatch with the information in information_schema.
2. Try to be clever and rewrite when we think that makes sense. This PR rewrites all queries where the query is a SELECT either without a FROM clause, or one with only dual in it. The thinking is that if the query is SELECT database() or something like that, we use the keyspace name. But if you pull in data from any other source than dual, we'll not handle it by rewriting and lean on mysqld to evaluate it for us.

Another heuristic we could use is to only rewrite database() in SELECT projections, but not in WHERE predicates.

Input is most welcome.

Thank you for the detailed analysis. The current implementation seems to be the most sensible option. Even though it is inconsistent, it gives us "working" behavior for all the cases you enumerated.

[morgo]

LGTM