Re: Operator class group proposal - Mailing list pgsql-hackers

[ replying to myself again, how tacky :-( ]

I wrote:
> BTW, I forgot to mention one of the motivations for that last
> restriction: I'm thinking it would be convenient to allow index
> declarations to accept either an opclass name or a class group name.
> Thus you could say "pattern_ops" instead of being specific about
> "varchar_pattern_ops" or "text_pattern_ops".

Some more thought about that yielded what might or might not be a good
idea: why not just collapse all the members of a "class group" into one
opclass?  In other words, not make a distinction between groups and
individual opclasses?  So for example, int2_ops int4_ops and int8_ops
would all collapse into one big opclass.

In SQL terms this would mean allowing several "FOR TYPE foo" clauses in
a single CREATE OPERATOR CLASS command, and we'd likely have to give up
the shorthand where you can omit argument types for operators (or at
least, it'd only work in the case where you say FOR TYPE just once).

At the system catalog level this'd require some rearrangement of
pg_opclass, and the unique keys for pg_amop and pg_amproc would probably
need another column, but it certainly seems doable.

One rather large objection is that existing pg_dump files may contain
references to specific opclasses such as "varchar_pattern_ops".  How
could we deal with converting that to a world where there's only one
"pattern_ops" opclass?  In the past we've resorted to hard-wired
substitutions in gram.y, but that got too bletcherous to bear quite
some time ago.  I'm thinking about allowing opclasses to have "aliases"
recorded in the system catalogs as a more general solution to the
problem; it'd let us get rid of those old hacks in gram.y, too.

The other thing that'd have to be dealt with is that for GIST and GIN,
the STORAGE clause needs to be associated with a specific indexable
type.  I'm thinking the syntax might be like

CREATE OPERATOR CLASS name USING index_method AS { [ DEFAULT ] FOR TYPE data_type [ STORAGE storage_type ] [ ALIAS name
] | OPERATOR strategy_number operator_name [ (op_type, op_type) ] [ RECHECK ]  | FUNCTION support_number funcname
(argument_type[, ...]) } [, ... ]
 

plus a backwards-compatible variant syntax where there's just one FOR TYPE
clause before the USING part.

With either this or the original proposal, or for that matter our
existing releases, there's a bit of an issue with needing to modify
existing opclasses.  Consider the situation of someone adding say
"tinyint" as a contrib module, and wanting it to interact reasonably
with the existing datatypes.  He has to create some cross-type
operators, which is no big deal, but then he needs to plug them into
already-existing opclasses, and there's no provision for doing that.
I had been thinking that the scheme of adding opclasses to a
pre-existing group would fix that, but it doesn't really: you still need
to add more cross-type operators to the existing group member opclasses.

So this leads me to think that we need to allowALTER OPERATOR CLASS foo ADD [ TYPE/OPERATOR/FUNCTION ]ALTER OPERATOR
CLASSfoo DROP [ TYPE/OPERATOR/FUNCTION ]
 
and the process for the would-be tinyint implementor is to add on
entries to an existing "numeric_ops" operator class, instead of
starting his own class.

Among other things this would require finer granularity in the
pg_depends entries, since dropping a type would involve deleting
elements of an opclass but not necessarily the whole thing.
(That may well mean that we still need an object equivalent to the
current per-datatype opclass, as something to be named in pg_depends;
in which case the above restructuring becomes largely syntactic sugar.)

It may be that the separate-GROUP approach is about as clean as this
once all the dust settles, but we'd still need to do something about
allowing additions to an existing operator class.

Thoughts?
        regards, tom lane