Re: RFD: schemas and different kinds of Postgres objects

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(at)gmx(dot)net