Re: Operator class group proposal

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Operator class group proposal
Date: 2006-12-15 23:57:22
Message-ID: 87ac1oiufx.fsf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Operator Superclass ?
>
> Yeah, I thought about that too, but I don't like it much ... can't
> entirely put my finger on why not, except that class/superclass usually
> implies that the objects you're talking about are all the same kind of
> thing, whereas what we have here is a very definite distinction between
> two kinds of objects.

I'm kind of glad to hear that since I had similar discomfort with it myself. I
thought it might be the least worst option though so I figured I would say it
out loud.

Perhaps something like

Operator Class
and
Data Type Class

Data type classes happens to involve operator classes but it sounds like
you're looking for them to specify other behaviours of how data types
inter-relate than just their operator classes anyways.

> On the same grounds, I'd object to calling schemas "directories" or
> "folders", unless they could be nested.

(Actually that's a bit of an odd case since real-world folders aren't
generally nestable and actually many early operating systems didn't allow them
to be nested either. We're just so used to the computer metaphor that we
forget what it's originally supposed to represent.)

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-16 00:04:17 Re: Operator class group proposal
Previous Message Tom Lane 2006-12-15 23:44:10 Re: Operator class group proposal