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