MDEV-31125 Add option for default local schema when I_S is queried

[LinuxJedi]

This adds the additional system variable information_schema_local_database. When this variable is enabled it will cause built-in INFORMATION_SCHEMA tables and SHOW commands to use the current database as the TABLE_SCHEMA when one has not been explicitly set in a query.

This is so that for hosting companies with thousands of databases, these queries that are in applications they cannot control do not hit the disk hard scanning all FRM files. These would not be relevant to the application anyway.

SHOW DATABASES will still show all databases and if there is no default database currently set then these commands will behave as normal.

• The Jira issue number for this PR is: MDEV-31125

How can this PR be tested?

Regression suite test added.

Basing the PR against the correct MariaDB version

• This is a new feature and the PR is based against the latest MariaDB development branch
• This is a bug fix and the PR is based against the earliest maintained branch in which the bug can be reproduced

Backward compatibility

New behaviour is off by default.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ LinuxJedi
❌ montywi
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[LinuxJedi]

Has been reviewed by @montywi. Amendments made:

• Changed the system variable description to make it more readable
• Changed the test case so that it doesn't use the mysql tables
• Added patches by Monty to add a description and remove a couple of strlen() uses

[vuvova]

This is weird. Normally, if such an application simply shouldn't have privileges on other schemas, then I_S automatically will only show one schema. Couldn't they do that instead?

[LinuxJedi]

This is weird. Normally, if such an application simply shouldn't have privileges on other schemas, then I_S automatically will only show one schema. Couldn't they do that instead?

As far as I can tell the privilege check happens at a table level, after the tables have been scanned. So, whilst it only shows a filtered list, it is scanning the FRMs. If the way I'm reading it is true, then that would not solve the problem.

[vuvova]

privileges on databases happen before tables are read. Or should happen, if they don't — we'll fix it.
Also, if only one database is allowed from privileges, I_S can read it directly, without even scanning the datadir (same optimization as for TABLE_SCHEMA = const

[LinuxJedi]

privileges on databases happen before tables are read. Or should happen, if they don't — we'll fix it. Also, if only one database is allowed from privileges, I_S can read it directly, without even scanning the datadir (same optimization as for TABLE_SCHEMA = const

Having run some tests and looked through the permissions section better, you are correct, but only at a table level. This patch still solves two problems:

1. Without a WHERE condition I_S will run a stat on every directory in the datadir, regardless of permissions. This is an expensive operation on hosting setups. When filtered with a WHERE condition (and with this patch) the stat is only on the required directory.
2. (a lesser case) There are cases where hosting companies will have multiple schemas under one user. The application likely only needs to know about one schema.

There may be some smart privilege check you can do for part 1 here but I suspect it will be complicated to code up as the privileges system gets more complicated.

[vuvova]

I don't see how these two are "problems". Looks to me like "works as expected". Otherwise I can point out to few more problems:

1. Without a WHERE condition a SELECT might do a full table scan. When filtered with an @@implicit_where_clause variable, this can be avoided and the user will only see what he wanted to see.
2. (a lesser case) There are cases when a user forgets to create the table before using it. With the @@implicit_create_table variable (that holds a full CREATE TABLE statement for such a table) the table can be automatically created as needed.

Back to the PR, why on Earth a user who runs a SELECT with a clear and well defined WHERE clause, gets the result limited by some user variable that he has to set beforehand?

[LinuxJedi]

Closing as we are going to do this a little differently