After some fooling around with gram.y, I have come to the conclusion
that there's just no way to use a schema-qualified name for an operator
in an expression. I was hoping we might be able to write something like
operand1 schema.+ operand2
but I can't find any way to make this work without tons of shift/reduce
conflicts. One counterexample suggesting it can't be done is that
foo.*
might be either a reference to all the columns of foo, or a qualified
operator name.
We can still put operators into namespaces and allow qualified names in
CREATE/DROP OPERATOR. However, lookup of operators in expressions would
have to be completely dependent on the search path. That's not real
cool; among other things, pg_dump couldn't guarantee that dumped
expressions would be interpreted the same way when reloaded.
Things we might do to reduce the uncertainty:
1. Keep operators as database-wide objects, instead of putting them into
namespaces. This seems a bit silly though: if the types and functions
that underlie an operator are private to a namespace, shouldn't the
operator be as well?
2. Use a restricted, perhaps fixed search-path for searching for
operators. For example, we might force the search path to have
pg_catalog first even when this is not true for the table name search
path. But I'm not sure what an appropriate definition would be.
A restricted search path might limit the usefulness of private operators
to the point where we might as well have kept them database-wide.
Comments anyone? I'm really unsure what's the best way to proceed.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
