CREATE/DROP OPERATOR CLASS - Mailing list pgsql-hackers

From Tom Lane
Subject CREATE/DROP OPERATOR CLASS
Date
Msg-id 19079.1027264848@sss.pgh.pa.us
Whole thread Raw
Responses Re: CREATE/DROP OPERATOR CLASS  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
Now that we have dependencies implemented, it would be a real good idea
if operator classes could be included in the web of dependencies.
However, the pg_depends code implicitly assumes that it can do a DROP,
if demanded, for any entity referenced by a dependency link.  This means
we need DROP OPERATOR CLASS.

I am thinking of picking up Bill Studenmund's patch from last fall for
CREATE OPERATOR CLASS and bringing it forward into current sources,
and adding DROP support too.

In our last episode, Peter said:
> I'm having a few issues with the syntax.

I *think* what we had agreed to was

CREATE OPERATOR CLASS name [ DEFAULT ] FOR TYPE type USING accessmethod
AS {   FUNCTION number name(parms)    | OPERATOR number name [ ( type, type ) ] [ RECHECK ]    | STORAGE typename  } [,
...]

... at least that's the last message in the thread I can find in my
archives.  Anyone unhappy with this?  (Obviously the names will now
need to include optional schema qualification.)

Drop will need to look approximately like

DROP OPERATOR CLASS name USING accessmethod

since opclass names are only unique within a specific index AM.

I don't think we'd discussed permissions issues.  My inclination
is to restrict CREATE to the owner of the underlying type, on the
grounds that letting other people do it interferes with the legitimate
rights of the type owner (cf my comments about creating casts,
yesterday).  I'm willing to listen to other arguments though.
We do have an "opcowner" column in pg_opclass, so in any case we
will record the creator and allow only him to do DROP.

Thoughts, objections?

I'm off to San Diego for a week for the O'Reilly convention, and
was casting about for some fairly self-contained project to take
with me for idle moments.  This looks like it would do...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] prepareable statements
Next
From: Oleg Bartunov
Date:
Subject: contrib/ltree for 7.2 or 7.3 ?