CREATE/DROP OPERATOR CLASS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: CREATE/DROP OPERATOR CLASS
Date: 2002-07-21 15:20:48
Message-ID: 19079.1027264848@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2002-07-21 15:38:16 contrib/ltree for 7.2 or 7.3 ?
Previous Message Dhruv Pilania 2002-07-21 03:36:56 PITR and rollback