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

From Tom Lane
Subject Re: Operator class group proposal
Date
Msg-id 21036.1166111936@sss.pgh.pa.us
Whole thread Raw
In response to Re: Operator class group proposal  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Operator class group proposal  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.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.

I'm not sure.  The problem that I'm seeing is that currently, cross-type
comparisons go into the opclass associated with their left-hand argument
type.  Therefore, if say you want to add "tinyint" to an opclass group,
you not only need to add an opclass for tinyint (containing tinyint vs
tinyint as well as tinyint vs other-type operators), but you also need
to add other-type vs tinyint operators to the *other* members of the
group.  So the notion of the classes being separate objects seems a bit
artificial to me.  I think that "if I want to make tinyint part of the
numeric_ops index opclass, I just add the type and all these operators to
that opclass" is at least as clear.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Security leak with trigger functions?
Next
From: Dave Page
Date:
Subject: Re: libpq.a in a universal binary