Re: Operator class group proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Operator class group proposal
Date: 2006-12-14 15:36:05
Message-ID: 20687.1166110565@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> writes:
> I think it would be easier to understand if we do not merge the
> opclasses for different types into one statement.

Agreed, huge CREATE OPERATOR CLASS commands would be no fun, which
is one reason for my recommendation to improve ALTER OPERATOR CLASS.
I think that in practice people would use ALTER to add one type at
a time to an opclass.

> Classes with the same name and
> index_method would implicitly be a class group.

[ itch... ] I've never cared for the idea that semantics should depend
fundamentally on the mere name of something. I think we want class
groups to be real objects in one form or another, not chance
associations. As a specific objection, under this rule it would never
become possible to allow unprivileged users to create opclasses, because
they could break the behavior of someone else's opclass just by creating
another one of the same name with not-really-compatible behavior.

> As an aside, Informix decided to name compatible operator functions
> identically and define an opclass as those names:

Interesting. Probably too much water under the bridge now for us to
consider forcing function/operator renames, though.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-14 15:41:16 Re: Solaris excesive semaphores usage.
Previous Message Tom Lane 2006-12-14 15:21:17 Re: recovery.conf parsing problems