Re: Oracle Style packages on postgres

Adding to the ambiguity is the dot notation used for
composite columns.  Don't forget the other end ignoring
those required parens.

is foo.bar.zap a database.schema.table a schema.table.columna table.column.column

--elein

On Wed, May 11, 2005 at 03:21:42PM -0400, Tom Lane wrote:
> "Dave Held" <dave.held@arraysg.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>