Re: Operator class group proposal

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Operator class group proposal
Date: 2006-12-14 11:28:41
Message-ID: E1539E0ED7043848906A8FF995BDA5790198F001@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-12-14 12:04:10 pg_standby
Previous Message Yoshiyuki Asaba 2006-12-14 11:13:34 pg_restore fails with a custom backup file