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