On Fri, Jun 4, 2021, at 18:03, Pavel Stehule wrote: > > > pá 4. 6. 2021 v 17:43 odesílatel Joel Jacobson <j...@compiler.org> napsal: >> __ >> Maybe this could work: >> CREATE SCHEMA schema_name UNQUALIFIED; >> Which would explicitly make all the objects created in the schema accessible >> unqualified, but also enforce there are no conflicts with other objects in >> existence in all unqualified schemas, upon the creation of new objects. > > Yes, it can work. I am not sure if "unqualified" is the best keyword, but the > idea is workable.
So maybe a combination of some kind of GUC to restrict search_path in some way, and a settable/unsettable new boolean pg_namespace column to control if the schema should be accessible unqualified or not? If we don't like "UNQUALIFIED" as a keyword, maybe we could reuse "PUBLIC"? Or will that be confusing since "PUBLIC" is also a role_specification? I think unqualified=true should mean a schema doesn't need to be part of the search_path, to be accessible unqualified. This means, "pg_catalog" and "public", might have unqualified=false, as their default values. Setting unqualified=true for "pg_catalog" and "public" would enforce there are no overlapping objects between the two. Marko, in your use-case with the "compat" schema, do you think it would work to just do ALTER SCHEMA compat DROP UNQUALIFIED (or whatever the command should be) when upgrading to the new major version, where compat isn't necessary, similar to changing the GUC to not include "compat"? IMO, the biggest disadvantage with this idea is that it undeniably increases complexity of name resolution further, since it's then yet another thing to take into account. But maybe it's worth it, if the GUC to restrict search_path, can effectively reduce complexity, when used in combination with this other proposed feature. I think it's a really difficult question. I strongly feel something should be done in this area to improve the situation, but it's far from obvious what the right thing to do is. /Joel
