Re: Operator class group proposal

> 
> 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.

IMHO, this is better than groups, but in any case exact opclass will be defined 
by pair: (opgroup, opclass) in first case or (opclass, alias) in second. Pair is 
needed to find support function(s). For instance, contrib/intarray makes two 
GiST opclasses with different storage types.
> I don't have any idea whether opclass groups would be useful for GiST or> GIN indexes, but maybe Oleg and Teodor can
thinkof applications.
 

I'm afraid it isn't  useful for GiST/GIN - strategies are not defined at all and 
planner can't known about semantic meaning of operation/strategies.

Examples of opclasses which can be joined in one group:
1) geometry opclasses
2)  gist__int_ops and gist__intbig_ops for GiST from contrib/intarray (BTW,    gin__int_ops for GIN supports the same
operationsand the same strategies    as gist__int*_ops)
 
3) some of opclasses from btree_gist.
4) builtin GIN oplasses for arrays and it possible to add cross-type operations 
for arrays ( ie int4[] && int8[] )



BTW, unpleasant behaviour of postgres:
postgres=# CREATE TABLE foo (a varchar);
postgres=# CREATE INDEX fooidx ON foo (a varchar_pattern_ops);
postgres=# ALTER OPERATOR CLASS varchar_pattern_ops USING btree RENAME TO bar;

% pg_dump postgres | psql wow
...
ERROR:  operator class "bar" does not exist for access method "btree"
...

May be, it will be useful to forbids altering/renaming of builtin objects...


-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/