Re: Oracle Style packages on postgres

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

In response to

Responses

Browse pgsql-hackers by date

  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