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

From Zeugswetter Andreas ADI SD
Subject Re: Operator class group proposal
Date
Msg-id E1539E0ED7043848906A8FF995BDA5790198F001@m0143.s-mxs.net
Whole thread Raw
In response to Re: Operator class group proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Operator class group proposal
List pgsql-hackers
> 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 allow
>     ALTER OPERATOR CLASS foo ADD [ TYPE/OPERATOR/FUNCTION ]
>     ALTER OPERATOR CLASS foo 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.

I think it would be easier to understand if we do not merge the
opclasses
for different types into one statement.

We would add type to the key and thus have:
CREATE OPERATOR CLASS name USING index_method FOR TYPE data_type  ...
DROP OPERATOR CLASS name USING index_method FOR TYPE data_type ...

I would then name the opclasses btree_ops (for the default btree
opclass)
with no reference to type, but only to functionality. (maybe we need to
diff text and number)
Classes with the same name and index_method would implicitly be a class
group.

I generally like the idea to simplify this area.

As an aside, Informix decided to name compatible operator functions
identically
and define an opclass as those names:
opclassname    owner        amid    opclassid    ops    support
btree_ops    informix    1    1
lessthan;lessthanorequal;equal;greaterthanorequal;greaterthan;    compare;
rtree_ops    informix    2    2
overlap;equal;contains;within;    union;size;inter;
This is also simple to use and understand.

Andreas


pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas ADI SD"
Date:
Subject: Re: Vacuum, analyze, and setting reltuples of pg_class
Next
From: Yoshiyuki Asaba
Date:
Subject: pg_restore fails with a custom backup file