RFD: schemas and different kinds of Postgres objects

Tom Lane wrote:

Continuing to think about implementing SQL schemas for 7.3 ...

Today's topic for discussion: which types of Postgres objects should
belong to schemas, and which ones should have other name scopes?

...

I am leaning towards keeping functions/operators database-wide, but would
like to hear comments. Is there any real value in, eg, allowing different
users to define different "+" operators *on the same datatypes*?

With regard to functions, I believe they should be schema specific.
Oracle allows the creation of procedures/functions in specific schema.
User2 may then execute user1's function as:

EXECUTE user1.myfunction();

However, as you suggest, the fully qualified naming of functions gets
messy. So Oracle allows (and I think we would need) PUBLIC SYNONYMs.
This allows user1 to do:

CREATE TABLE employees(key integer, name VARCHAR(20));

CREATE SEQUENCE s;

CREATE PROCEDURE newemployee(n IN VARCHAR)
AS
BEGIN
INSERT INTO employees
SELECT s.nextval, n
FROM DUAL;
END;
/

GRANT INSERT ON employees TO user2;
GRANT EXECUTE ON newemployee TO user2;
CREATE PUBLIC SYNONYM newemployee FOR user1.newemployee;

Now, user2 just does:

EXECUTE newemployee(10);

In fact, with regard to the package discussion a while back, Oracle
allows this:

Database->Schema->Package->Procedure

and this:

Database->Schema->Procedure

and effectively this:

Database->Procedure via Database->PUBLIC Schema->Procedure

I really think that the main purpose of schemas is to prevent an
ill-informed or malicious user from engaging in unacceptable behavior.
By placing everything in schemas, it allows the Oracle DBA to have a
very fine-grained control over the ability of user1 to interfere with
user2. Before user1 above could pollute the global namespace, the dba
must have:

GRANT user1 CREATE PUBLIC SYNONYM

privilege, or created the synonym himself. This allows things like
pg_class to reside within their own schema, as well as all built-in
PostgreSQL functions. After the bootstrapping, PUBLIC SYNONYMs are
created for all of the system objects which should have global scope:

CREATE PUBLIC SYNONYM pg_class FOR system.pg_class;
CREATE PUBLIC SYNONYM abs(int) FOR system.abs(int);

One major benefit of Oracle is that the DBA, through the use of
STATEMENT privileges (i.e. GRANT CREATE TABLE to user1), resource
PROFILEs, and TABLESPACES can easily admin a database used by 20
different deparments and 1000 different users without the fear that one
might step on the other's toes. If the accounting department wants to
create an addtax() function, it shouldn't have to ask the receiving
deptartment to do so.

Just my thoughts,

Mike Mascari
mascarm@mascari.com

Tom Lane writes:

languages Probably should not be in schemas
access methods Probably should not be in schemas
opclasses See below
operators See below
functions/procedures See below
aggregates Should treat same as regular functions
constraints See below
rules See below
triggers See below
NOTIFY conditions See below

Remember that a schema is a named representation of ownership, so anything
that can be owned must be in a schema. (Unless you want to invent a
parallel universe for a different kind of ownership, which would be
incredibly confusing.) Also remember that we wanted to use schemas as a
way to prevent unprivileged users from creating anything by default. So
it would be much simpler if "everything" were in a schema.

I wouldn't worry so much about the invocation syntax -- if you don't like
ugly don't make ugly. For instance, if you add a user-defined operator
you would probably either put it in the same schema with the rest of your
project or put it in some sort of a global or default schema (to be
determined) to make it available to the whole system, my assumption being
that either way you don't need to qualify the operator. But the important
thing is that you *could* make cross-schema operator calls, say during
development or testing.

Consequentially, I opine that all of the things listed above should be in
a schema. (Although I don't have a strong opinion about notifications,
yet.)

namespace. Finally, SQL99 doesn't appear to think that operator and
function names are schema-local; though that may just be because it hasn't
got user-defined operators AFAICT.

Check clause 10.4 <routine invocation>: routine names are (optionally)
schema qualified like everything else.

Rewrite rules are currently required to have a name unique within their
database. We clearly don't want that to still be true in the schema
environment. Personally I would like to make rules' names unique only
among rules on the same table (like we handle triggers). That would
mean an incompatible change in the syntax of DROP RULE: it'd have to
become DROP RULE rule ON table, much like DROP TRIGGER. Is that okay?
If not, probably we must make rulenames local to schemas and say they
implicitly belong to the schema of the associated table.

I'd rather make the opposite change (make trigger names schema-global)
because that aligns with SQL99 and it would make more sense for overall
consistency (e.g., you can't have indexes with the same names on different
tables). The syntax change would also be backward compatible. I think
either way, schema-global or table-global namespace, can be argued to be
more useful or more confusion-prone, so I side with the standard on this
one.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Remember that a schema is a named representation of ownership, so anything
that can be owned must be in a schema. (Unless you want to invent a
parallel universe for a different kind of ownership, which would be
incredibly confusing.)

I don't buy that premise. It's true that SQL92 equates ownership of a
schema with ownership of the objects therein, but AFAICS we have no hope
of being forward-compatible with existing database setups (wherein there
can be multiple tables of different ownership all in a single namespace)
if we don't allow varying ownership within a schema. I think we can
arrange things so that we are upward compatible with both SQL92 and
the old way. Haven't worked out details yet though.

Have to run, more later.

regards, tom lane

FYI: Applications like Data Architect would benefit from a consistent and
complete interface to the schema. For example; I found that we had to bypass
the DD views which exist (as I recall) because they did not give us all
information we needed. So we selected stuff from the system tables directly.
Yucky. Sorry I can not recall details but thought that I would mention this
here. The MySQL 'SHOW' statements seem to work pretty well and shields us
from changes to the system tables.

Peter

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Remember that a schema is a named representation of ownership, so anything
that can be owned must be in a schema. (Unless you want to invent a
parallel universe for a different kind of ownership, which would be
incredibly confusing.)

I don't buy that premise. It's true that SQL92 equates ownership of a
schema with ownership of the objects therein, but AFAICS we have no hope
of being forward-compatible with existing database setups (wherein there
can be multiple tables of different ownership all in a single namespace)
if we don't allow varying ownership within a schema. I think we can
arrange things so that we are upward compatible with both SQL92 and
the old way. Haven't worked out details yet though.

Peter is right. Schemas is just a practical way of creating things
under
the same authorization-id + crating a namespace so that different
authorization-ids can have objects with the same (unqualified name).

Quoting Date (pg. 221): "The schema authID for a given schema identifies
the owner of that schema (and hence the owner of everything described by
that schema also)."

It is very important that we reach a conclusion on this as it simplifies
things a lot.

Regards,
Fernando

P.S.: That is why I was telling you that, except for the namespace part,
we already have the groundwork for Entry-level SQL-Schemas (where the
schema is always the authorization-id of the creator) -- it is just
a question of handling the "owner" appropriately.

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

Fernando Nasser <fnasser@redhat.com> writes:

Tom Lane wrote:

I don't buy that premise. It's true that SQL92 equates ownership of a
schema with ownership of the objects therein, but AFAICS we have no hope
of being forward-compatible with existing database setups (wherein there
can be multiple tables of different ownership all in a single namespace)
if we don't allow varying ownership within a schema.

Quoting Date (pg. 221): "The schema authID for a given schema identifies
the owner of that schema (and hence the owner of everything described by
that schema also)."

Yes, I know what the spec says. I also think we'll have a revolt on our
hands if we don't make it possible for existing Postgres applications to
continue working as they have in the past --- and that means allowing
tables of different ownerships to be accessible in a single namespace.

Although I haven't thought through the details yet, it seems to me that
a solution exists along these lines:

1. The creator of an object owns it. (With some special cases, eg the
superuser should be able to create a schema owned by someone else.)

2. Whether you can create an object in a schema that is owned by someone
else depends on permissions attached to the schema. By default only
the owner of a schema can create anything in it.

3. SQL92-compatible behavior is achieved when everyone has their own
schema and they don't grant each other create-in-schema rights.
Backwards-compatible behavior is achieved when everyone uses a
shared "public" schema.

We'd probably need GUC variable(s) to make it possible to choose which
behavior is the default. I haven't thought much about exactly what
knobs should be provided. I do think we will want at least these two
knobs:

1. A "search path" that is an ordered list of schemas to look in
when trying to resolve an unqualified name.

2. A "default schema" variable that identifies the schema to create
objects in, if a fully qualified name is not given.

The default creation location shouldn't be hardwired to equal the
front of the search path, because the front item of the search path
is probably always going to be a backend-local temporary schema
(this is where we'll create temporary tables).

The most dumbed-down version of this that would work is to reduce the
search path to just a fixed list of three locations: temp schema, a
selectable default schema (which is also the default creation location),
and a system schema (where pg_class and friends live). But a
user-settable path wouldn't be any more effort to support, and might
offer some useful capability.

regards, tom lane

Tom Lane wrote:

Quoting Date (pg. 221): "The schema authID for a given schema identifies
the owner of that schema (and hence the owner of everything described by
that schema also)."

Yes, I know what the spec says. I also think we'll have a revolt on our
hands if we don't make it possible for existing Postgres applications to
continue working as they have in the past --- and that means allowing
tables of different ownerships to be accessible in a single namespace.

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.

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.

For the current users, (based on your idea below) a default behavior of
searching the current-AuthID schema, them the "default" schema them
"any"
schema will probably make things work.

Fernando

P.S.: Note that the standard has no GRANTs for SCHEMAs themselves; all
GRANTS go to the specific objects as before.

Although I haven't thought through the details yet, it seems to me that
a solution exists along these lines:

1. The creator of an object owns it. (With some special cases, eg the
superuser should be able to create a schema owned by someone else.)

2. Whether you can create an object in a schema that is owned by someone
else depends on permissions attached to the schema. By default only
the owner of a schema can create anything in it.

3. SQL92-compatible behavior is achieved when everyone has their own
schema and they don't grant each other create-in-schema rights.
Backwards-compatible behavior is achieved when everyone uses a
shared "public" schema.

We'd probably need GUC variable(s) to make it possible to choose which
behavior is the default. I haven't thought much about exactly what
knobs should be provided. I do think we will want at least these two
knobs:

1. A "search path" that is an ordered list of schemas to look in
when trying to resolve an unqualified name.

2. A "default schema" variable that identifies the schema to create
objects in, if a fully qualified name is not given.

The default creation location shouldn't be hardwired to equal the
front of the search path, because the front item of the search path
is probably always going to be a backend-local temporary schema
(this is where we'll create temporary tables).

The most dumbed-down version of this that would work is to reduce the
search path to just a fixed list of three locations: temp schema, a
selectable default schema (which is also the default creation location),
and a system schema (where pg_class and friends live). But a
user-settable path wouldn't be any more effort to support, and might
offer some useful capability.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

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

OK, so the proposal is that we dissociate the ownership from the
namespace when we implement our version of SQL-Schemas, right?
This way an object will have both an owner and a schema (while in
the standard they are the same thing).

The important is not much to accommodate someone who is creating
schemas (a new thing, so objects can be created the "right" way)
but rather to accommodate current code that does not use schemas
and have several owners for the objects (which would all fall
into a "default" schema). Can you agree with that?

I was looking to see if we choose the proper defaults and search paths
and the "default" schema we could make it look for SQL-compliant code
as if it was a vanilla SQL-Schemas implementation.

To support the current database schema definitions (without SQL-Schemas
and with different owners), things would be created with the current
user authorization id and will have its name defined in the "default"
SQL-Schema
namespace. Also, when referring to an object if the name is not
qualified
with the schema name, the search would go through the schema with the
current authorization id (as required by the std) and proceed to check
the "default" schema.

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?
Will we pass the conformance tests? (I saw tests that test the schema
name
that is assumed when referencing but I do not recall seeing one that
tests
what is assumed on creation -- things I saw were all created inside
CREATE SCHEMA statements. Note, also, that passing the NIST tests
doesn't
make us compliant if we know that we are doing something different than
what is specified -- it just means that we got away with it :-)

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

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

Tom Lane wrote:

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.

Then we can live just with the schema being the ownership.

Switches set to standard:

schema search path = ("user's own schema", postgres)

[ default creation schema = user's own schema ] same as below,
we don't need this
switch

Switches set to historical:

schema search path = (user's own schema, "any" schema, postgres)

[ default creation schema = user's own schema ]

The searching in "any" schema (i.e., any owner) will let will find
things that where defined the way they are today, i.e., possibly
by several different users.

P.S.: You can even add the "default" schema in the standard case and
I believe you are still compliant and can handle things easier:
schema search path = ("user's own schema", postgres)

Maybe you could give an example of a case where the schema meaning
ownership breaks things. Or what kind of additional things you have
in mind that would require orthogonal schema and ownership spaces.

Regards,
Fernando

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

Fernando Nasser <fnasser@redhat.com> writes:

Switches set to historical:

schema search path = (user's own schema, "any" schema, postgres)

[ default creation schema = user's own schema ]

The searching in "any" schema (i.e., any owner) will let will find
things that where defined the way they are today, i.e., possibly
by several different users.

No, it won't, because nothing will ever get put into that schema.
(At least not by existing pg_dump scripts, which are the things that
really need to see the historical behavior.) The
default-creation-schema variable has got to point at any/public/
whatever-we-call it, or you do not have the historical behavior.

regards, tom lane

Tom Lane wrote:

Fernando Nasser <fnasser@redhat.com> writes:

Switches set to historical:

schema search path = (user's own schema, "any" schema, postgres)

[ default creation schema = user's own schema ]

The searching in "any" schema (i.e., any owner) will let will find
things that where defined the way they are today, i.e., possibly
by several different users.

No, it won't, because nothing will ever get put into that schema.
(At least not by existing pg_dump scripts, which are the things that
really need to see the historical behavior.) The
default-creation-schema variable has got to point at any/public/
whatever-we-call it, or you do not have the historical behavior.

You did not understand what I meant by "any". It is not a schema
called "any". It is _any_ schema.

Example:

A creates a table (do not specify the schema) so it gets into
the schema named A (as per standard).

B refers to the table without qualifying it...

In the standard case: look into schema B (=> not found), not in
postgres either.
ERROR: Inv. relation As the standard requires.

In the historical mode: look into schema B (=> not found), look into
ANY
schema (finds it in A). Works as it is today.

Note that I only suggest looking in B first (in the historical case)
because
this will allow for the coexistence of the current mode with a
quasi-compliant
use of SQL-Schemas. You only need to change the switch if you want
strict
compliance.

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

Fernando Nasser <fnasser@redhat.com> writes:

In the historical mode: look into schema B (=> not found), look into
ANY schema (finds it in A). Works as it is today.

No, it doesn't work the same as today, because in that implementation
both A and B can create the same tablename without complaint. It then
becomes very unclear which instance other people will get (unless your
"any" placeholder somehow implies a search order).

The idea of being able to put an "any" placeholder into the search list
is an interesting one, though. If we can resolve the ambiguity problem
it might be a useful feature.

I am a little troubled by the idea of placing "any" before the system
schema (what if JRandomLuser creates a table named "pg_class"?) but it
might be workable at the tail end of the path.

regards, tom lane

Tom Lane wrote:

Fernando Nasser <fnasser@redhat.com> writes:

In the historical mode: look into schema B (=> not found), look into
ANY schema (finds it in A). Works as it is today.

No, it doesn't work the same as today, because in that implementation
both A and B can create the same tablename without complaint.

I agree that we won't be able to catch this as an error unless we turn
another switch that requires unique names (there goes one of the
advantages
of having schemas, but there is always the option of leaving it on).

In this case it would be more close to the current behavior but what is
left of the SQL-Schemas will be more of a syntactic sugar (although it
can
be still used by the DBA to better organize the grant of privileges).

Anyway, it would be a DBA option to live with not detecting duplicate
names. And, I hope all our tools, graphical or not, will make it clear
what
is the schema things are defined into, so it would not be difficult to
figure out what is going wrong if something goes wrong (and we can also
print the relation oid on messages).

It then
becomes very unclear which instance other people will get (unless your
"any" placeholder somehow implies a search order).

If someone is just using the current mode, there shouldn't be (all names
are
database-unique).

The only case where this situation can happen is if someone is trying
to use schemas and the historical non-schema organization in the same
database, right? Can we make the search order per database?)

One possibility is to state that this is not recommended (one should
organize things as schemas or not at all in a database) and say that
the search order, besides the current AuthId, is unspecified (random).

Another possibility is to allow only one object with that name in the
"any" space. If someone means an object that was defined on a schema,
he/she can qualify the name with the schema (good practice). The only
case where this is not possible is the legacy case, where there is
exactly one object with that name anyway.

I prefer this second solution.

The idea of being able to put an "any" placeholder into the search list
is an interesting one, though. If we can resolve the ambiguity problem
it might be a useful feature.

See above.

I am a little troubled by the idea of placing "any" before the system
schema (what if JRandomLuser creates a table named "pg_class"?) but it
might be workable at the tail end of the path.

Yes, I thought of that as I was typing, but it was not the important
point at that time. You're right, should go at the end.

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

Tom Lane writes:

I don't buy that premise. It's true that SQL92 equates ownership of a
schema with ownership of the objects therein, but AFAICS we have no hope
of being forward-compatible with existing database setups (wherein there
can be multiple tables of different ownership all in a single namespace)
if we don't allow varying ownership within a schema.

We could have a Boolean knob that says "if you don't find the object in
the default schema, search all other schemas". That should provide all
the backward compatibility we need. Moreover, I figure if we do it that
way, the whole schema implementation reduces itself mostly to parser work,
no complicated system catalog changes, no complex overhaul of the
privilege system -- at least initially.

--
Peter Eisentraut peter_e@gmx.net

Tom Lane writes:

No, it doesn't work the same as today, because in that implementation
both A and B can create the same tablename without complaint. It then
becomes very unclear which instance other people will get (unless your
"any" placeholder somehow implies a search order).

The "search any schema" switch is only intended for use with legacy
databases, where duplicate names don't occur anyway. If someone uses it
with a new schema-using database design, then he kind of ought to know
that the switch probably doesn't make a whole lot of sense. However, to
get reproduceable behaviour anyway we can just define a search order, such
as by schema name.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Moreover, I figure if we do it that
way, the whole schema implementation reduces itself mostly to parser work,
no complicated system catalog changes, no complex overhaul of the
privilege system -- at least initially.

Why are you guys so eager to save me work? I'm not in the least
interested in implementing a "schema" feature that can only handle
the entry-level user == schema case. Therefore, just relabeling the
owner column as schema isn't an interesting option.

I really don't see what's wrong with building a namespace mechanism
that is orthogonal to ownership and then using that to implement what
SQL92 wants. I think this will be cleaner, simpler, and more flexible
than trying to equate ownership with namespace.

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

No, it doesn't work the same as today, because in that implementation
both A and B can create the same tablename without complaint. It then
becomes very unclear which instance other people will get (unless your
"any" placeholder somehow implies a search order).

The "search any schema" switch is only intended for use with legacy
databases, where duplicate names don't occur anyway.

That's a mighty narrow view of the world. Do you think that people had
better convert to SQL schemas before they ever again create a table?
The fact is that ordinary non-schema-aware usage will certainly lead to
the above scenario.

that the switch probably doesn't make a whole lot of sense. However, to
get reproduceable behaviour anyway we can just define a search order, such
as by schema name.

Or say that you get an "ambiguous reference" error if there is more than
one possible candidate in the "any" namespace. (Although that opens the
door for innocent creation of a table foo by one user to break other
people's formerly-working queries that reference some other foo.)
Bottom line for me is that this is an untried concept. I think the
concept of an "any" searchlist entry is risky enough that I don't much
want to hang the entire usability of the implementation on the
assumption that we won't find any fatal problems with "any".

However, the argument over whether SQL92's concept of ownership should
be taken as gospel is not really the argument I wanted to have in this
thread. Is it possible to go back to the original point concerning
whether there should be different namespace boundaries for different
types of objects? You aren't going to avoid those issues by saying that
namespace == ownership is good enough.

I'm particularly troubled by the idea of trying to apply this "any"
lookup concept to resolution of overloaded operators and functions.
Suppose I have a reference func(type1,type2) that I'm trying to resolve,
and I have an inexact match (one requiring coercion) in my own schema.
Do I look to the "any" schema to see if there are better matches?
If so, what happens if the "any" schema contains multiple possibilities
with identical signatures (presumably created by different users)? ISTM
this will positively guarantee a resolution failure, since there's no
way for the resolver to prefer one over another. Thus, by creating
a "func(foo,bar)" function --- quite legally --- JRandomLuser might
break other people's formerly working queries that use other functions
named func. Although it's possible for this to happen now, it'll be
a lot more surprising if JRandomLuser thinks that his functions live
in his own private schema namespace.

I'm thinking that the overloading concept is not going to play well
at all with multiple namespaces for functions or operators, and that
we'd be best off to say that there is only one namespace (per database)
for these things.

regards, tom lane