From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dave Held" <dave(dot)held(at)arraysg(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Oracle Style packages on postgres |
Date: | 2005-05-11 19:21:42 |
Message-ID: | 14105.1115839302@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Dave Held" <dave(dot)held(at)arraysg(dot)com> writes:
> /*
> * We check the catalog name and then ignore it.
> */
> if (!isValidNamespace(name[0]))
> {
> if (strcmp(name[0], get_database_name(MyDatabaseId)) != 0)
> ereport(ERROR,
Which more or less proves my point: the syntax is fundamentally
ambiguous. I suppose people would learn not to use schema names that
match the database they are in, but that doesn't make it a good idea to
have sensible behavior depend on non-overlap of those names.
[ thinks for awhile ... ]
OTOH, what if we pretended that two-level-nested schemas ARE catalogs
in the sense that the SQL spec expects? Then we could get rid of the
pro-forma special case here, which isn't ever likely to do anything more
useful than throw an error anyway. Thus, we'd go back to the pre-7.3
notion that the current Postgres DB's name isn't part of the SQL naming
scheme at all, and instead handle the spec's syntax requirements by
setting up some conventions that make a schema act like what the spec
says is a catalog.
There are some nontrivial issues to be thought about here, like under
what conditions "CREATE SCHEMA foo" ought to create a top-level schema
versus creating a schema under some other schema that we are pretending
is the active "catalog". But it seems on first glance like something
could be worked out.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GUNDUZ | 2005-05-11 19:23:31 | Re: 7.3.10 working |
Previous Message | Tom Lane | 2005-05-11 18:32:38 | Re: [PATCHES] plperl and pltcl installcheck targets |