Re: Operator class group proposal

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> I think it may be useful to maintain the distinction between groups and
> classes for users, because at that level the whole concept is easier to
> understand. Dropping and recreating operator classes is easier to
> handle than playing strange tricks with ALTER OPERATOR CLASS GROUP. And
> probably easier to get right/harder to screw up.

After further thought I'm beginning to see the merits of this
suggestion. The consideration that drives it is this: what is an index
going to depend on in pg_depends? If we have a massive operator class
handling multiple types, we certainly don't want to have to drop every
index using that opclass if we want to drop just one of the datatypes.
(This would be especially true for things like "numeric_ops" which would
support both user indexes and system catalogs ... after adding "tinyint"
to that, what if you want to back it out again?) So it seems like in a
multi-type-operator-class system there'd still have to be an explicit
notion of an opclass-and-indexed-datatype combination --- which we might
as well keep calling an operator class for old times' sake. So we're
back to calling the larger structure an "operator class group" unless
someone's got a better idea.

However, thinking about the effects of DROP leads me to suggest that an
operator class in this sense should ideally contain only the "core"
stuff that you must have to support an index on a column of its
datatype. In particular, cross-type comparisons are generally not
"core", and could be dropped without breaking indexes that use the
class. So I suggest that cross-type comparison operators could be
declared to be members of an operator class group but not directly
members of any one of its operator classes.

In other words the object hierarchy looks like

Operator class group

Operator class

"core" ops and support functions for class

Operator class

"core" ops and support functions for class

...

Cross-type ops and support functions

The dependencies would be set up so that dropping a "core" operator
forces dropping its operator class and any dependent indexes, same
as today. But dropping a cross-type op doesn't force anything,
and an operator class group per se never goes away unless explicitly
destroyed. (It could validly exist with no contained objects, in
fact that would be its initial state.)

I think the CREATE OPERATOR CLASS GROUP command becomes just

CREATE OPERATOR CLASS GROUP name USING am;

and then you add opclasses to it by creating them with a GROUP
option used in CREATE OPERATOR CLASS, and/or add individual cross-type
ops to it with an ALTER command that would look like

ALTER OPERATOR CLASS GROUP name ADD { OPERATOR ... | FUNCTION ... } ...

As now, there's no ALTER OPERATOR CLASS, you can only drop the whole
thing (with any dependent indexes) and re-create it. This seems a good
idea because we lack any infrastructure for rebuilding dependent indexes
after an opclass redefinition. That doesn't seem like a problem for
fooling with individual cross-type ops in a class group though.

For backwards compatibility, we'd still accept cross-type ops listed in
CREATE OPERATOR CLASS, but this would be deprecated for the reason that
dropping such an op would force dropping the class (as indeed it does
today) and obviously you'd rather not have indexes dependent on non-core
operators. Note that which operators are "core" to an opclass is not
hardwired into this structure, it's the class author's choice.

> How the backend implements it may be easier as one single large
> opclass. Essentially the operater class table becomes merely a
> placeholder for the name (maybe also aliases?), which can still be used
> in index declarations, but is never used by the backend otherwise.

To represent this cleanly in the catalogs, we'd probably want nominally
stand-alone opclasses to belong to implicitly created single-member
groups, because the individual entries in pg_amop and pg_amproc are
always going to be shown as belonging to groups --- the membership
hierarchy above is only interesting in pg_depends, not for index
operations. I think that's about the same thing you're saying here.

Comments?

regards, tom lane