On Wed, Jun 2, 2021 at 10:43:10AM -0400, Jim Mlodgenski wrote: > On Wed, Jun 2, 2021 at 9:58 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > In the first place, what do you think the primary key of pg_namespace is > > now? > > In the patch the unique constraint is (nspname, nspnamespace) which is > certainly awkward. I initially went down the pg_module route to avoid > adding another catalog, but in retrospect, that may be a cleaner way. > > > > It's already quite hard to tell which part > > of a multiply.qualified.name is which, given that SQL says that you can > > optionally put a "catalog" (database) name in front of the others. > > I really doubt there is a way to shoehorn sub-schemas in there without > > creating terrible ambiguities. Is "a.b.c" a reference to object c in > > schema b in database a, or is it a reference to object c in sub-schema b > > in schema a? > > That was the area I had the most difficult part to reason about. I tried to > make > some simplifying assumptions by checking if "a" was the current database. > Since we don't support cross database access, if it was not, I assumed "a" > was a schema. I not sure if that would be valid, but it did scope things > to a more manageable problem.
If we go in this direction, I assume we would just disallow a schema name matching the database name. CREATE DATABASE with TEMPLATE would have to check that. Also the common case where you create a database name to match the user name, and also a schema inside to match the username, would have to be disallowed, e.g. creating a 'postgres' schema to match the 'postgres' user in the 'postgres' database. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
