To: Fernando Nasser <fnasser@redhat.com>
cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Subject: Re: RFD: schemas and different kinds of Postgres objects 
In-reply-to: <3C4D96C5.80BBF764@redhat.com> 
References: <Pine.LNX.4.30.0201211840260.687-100000@peter.localdomain>
	<12239.1011661590@sss.pgh.pa.us> <3C4D8A39.FF79CDC4@redhat.com>
	<15339.1011716171@sss.pgh.pa.us> <3C4D96C5.80BBF764@redhat.com>
Comments: In-reply-to Fernando Nasser <fnasser@redhat.com>
	message dated "Tue, 22 Jan 2002 11:43:49 -0500"
Date: Tue, 22 Jan 2002 11:51:30 -0500
Message-ID: <15638.1011718290@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Fernando Nasser <fnasser@redhat.com> writes:
> But them it is not SQL-Schemas.  Call it something else, "packages"
> for instance.  The standard has lots of rules and other considerations
> all around the document that depend on schemas have the meaning they 
> assigned to it.

Where?  And are there any cases where it really matters?

> If someone wants to really make use of SQL-Schemas, he/she will need to 
> reorg the database anyway, which will probably mean dumping the data,
> massaging the DLL and recreating it.  I guess most users of SQL-Schemas
> will be people creating new databases.

No doubt.  That still leaves us with the problem of providing
backward-compatible behavior in an engine that is going to be designed
to support schemas.  I'm not sure what you think the implementation of
schemas is going to look like --- but I think it's not going to be
something that can be turned off or ignored.  Every table is going to
belong to some schema, and the old behavior has to be available within
that framework.

We are not working in a vacuum here, and that means that "implement
the specification and nothing but" is not a workable design approach.
We are going to end up with something that does the things SQL92 asks
for, but does other things too.

			regards, tom lane