pg-ext: add more SQL func wrappers

[fantix]

Adds wrappers for:

• has_database_privilege
• has_any_column_privilege

has_any_column_privilege is needed by Metabase introspecting the schema.

Also added an internal util function to_regclass() that uses parse_ident() to imitate the actual to_regclass(). This may potentially replace the current compiler-backed to_regclass(), but I'd keep this PR small.

The pg_database view was broken, fix that too.

• Fix namespaced table names
• Fix broken pg_database view
• Add test

Refs #5307, #5319
Fixes #8457

[elprans]

This is icky. Relation names might not be unique across schemas so a "subquery returned more than one row" is possible. You need to take search_path into account (via current_schemas()?).

[aljazerzen]

Yes, we would have to take search_path into account.

But not our internal search path accessible via current_schemas, but the search_path we expose to the user. That is passed to pg_resolver in ResolverOptions and is (currently) not accessible at runtime in SQL.

[aljazerzen]

Oh, I remember now: there is cast_to_regclass and to_regclass in static.py. They do the "search_path" part statically and generate SQL for runtime introspection.

They also handle all supported ways of expressing a regclass.

[fantix]

is (currently) not accessible at runtime in SQL.

Does that mean this PR needs to be re-done in the compiler? Or I should just make search_path available in the _edgecon_state temp table?

there is cast_to_regclass and to_regclass in static.py.

Yeah, that's what I meant by:

This may potentially replace the current compiler-backed to_regclass(), but I'd keep this PR small.

Actually, I'd like to move forward with the search_path issue unfixed like it has been for months (but with some strong comments/warnings in code, and a limit 1 mitigation) and solve the namespace and quoting issue first.

Because it's much worse that this doesn't work:

main=# select has_table_privilege('"TypeWithUniqueName"', 'update');
 has_table_privilege
---------------------

(1 row)

(Because it's more likely to have case-sensitive names with Gel schemas, that require quoting in SQL. The current 6.3 server mistakingly supports the unquoted has_table_privilege('TypeWithUniqueName', ..) but not the properly quoted has_table_privilege('"TypeWithUniqueName"', ..), not to mention namespaced names.)

... rather than baring with this being inaccurately correct:

main=# select has_table_privilege('"TypeWithDupNameInDiffModules"', 'update');
 has_table_privilege
---------------------
 t
(1 row)

(This behaves the same as the current 6.3 server, whose implementation SQL is also returning multiple rows, I think the function wrapper implicitly aggregated the bools and took the first row?)

It's still better if we can fix it properly, it's just seemingly a much larger changeset. Thoughts? I'm fine with either 1 PR or 2.

[elprans]

BTW, the compiler implementation of to_regclass is also wrong, because it only takes into account the top search path and it should search the whole stack, including the implicit entries (i.e pg_catalog).

[aljazerzen]

I agree has_table_privilege is a much higher priority than regclass. I'd suggest moving impl of to_regclass to SQL in a separate PR, because it might get large and complex.

[fantix]

I'll start a new PR to apply the application-level search_path in the backend as an opaque value, and reimplement sql.to_regclass properly.

[aljazerzen]

Looks good apart from to_regclass thing.

[fantix]

Merged and explained in the commit message:

If the same table name exists in more than one schema, the has*_privilege() functions that take an unqualified table name are not yet looking into search_path as they are expected to be, but rather choose a "random" one as the result. This is not a problem yet, because Gel user is "superuser" only, it has access to any of the tables with the same name, so the result is inaccurately correct.