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 think of 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 operations and 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/