From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: RFD: schemas and different kinds of Postgres objects
Date: Tue, 22 Jan 2002 15:41:49 -0500
Message-ID: <28199.1011732109@sss.pgh.pa.us> (raw)
In-Reply-To: <3C4DCBDB.689D7201@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>
<15638.1011718290@sss.pgh.pa.us>
<3C4DCBDB.689D7201@redhat.com>
Fernando Nasser <fnasser@redhat.com> writes:
> The only problem in the scenario above is that the standard says that
> when creating objects and not specifying the schema the schema name
> should be assumed to be the current user authorization id (or whatever
> authorization id the code is running as). In our case it would go to
> the default schema. If someone wants the SQL std behavior then, he/she
> must create things inside a CREATE SCHEMA statement or explicitly
> qualify
> with the schema name the objects being created. Can we live with
> that?
Huh? You seem to be assuming that we need to support both the
historical Postgres behavior and the SQL-standard behavior with exactly
the same configuration switches. That's not how I'm seeing it at all.
The way I'm envisioning it, you could get either the historical
behavior, or the standard's behavior, depending on how you set up the
configuration variables. I don't see any particular reason to limit the
system to just those two cases, either, if the underlying implementation
has enough flexibility to support custom namespace configurations.
I believe that we could get the historical behavior with something like
schema search path = ("public" schema, system schema);
default creation schema = "public" schema
and the standard's behavior with something like
schema search path = (user's own schema, system schema);
default creation schema = user's own schema
(ignoring the issue of a schema for temp tables for the moment).
If you prefer to think of these things as "namespaces" rather than
"schemas", that's fine with me ... what we're talking about here
is an implementation that can support SQL-style schemas, but isn't
narrowly able to do only that.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, fnasser@redhat.com, peter_e@gmx.net
Subject: Re: RFD: schemas and different kinds of Postgres objects
In-Reply-To: <28199.1011732109@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox