On Wed, Jun 2, 2021 at 10:43:10AM -0400, Jim Mlodgenski wrote:
> On Wed, Jun 2, 2021 at 9:58 AM Tom Lane <tgl@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 <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.