Re: @ versus ~, redux

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: andrew(at)supernews(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: @ versus ~, redux
Date: 2006-09-04 14:45:55
Message-ID: 23762.1157381155@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
> On 2006-09-04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Do we all agree on this:
>>
>> "x @> y" means "x contains y"
>> "x @< y" means "x is contained in y"

> While I suggested something like those, I would also suggest that the
> existing operators for inet/cidr be taken into consideration:

> x >>= y "x contains y"
> x >> y "x strictly contains y"
> x <<= y "x is contained in y"
> x << y "x is strictly contained in y"

As I commented to Michael, adopting these names for geometric inclusion
seems unworkable because << and >> already mean "is left of" and "is
right of" for those datatypes. We'd have to rename those operators too.
Also, if we wanted to implement both strict and nonstrict containment
operators, we're suddenly talking about adding code not only catalog
entries. So that sounds like an awful lot of work and a whole lot more
user code affected, in return for not that much gain in consistency.

The existing geometric containment tests seem to be nonstrict, so if we
wanted to leave room to add strict ones later, it might be best to
settle on

x @>= y x contains or equals y
x <=@ y x is contained in or equals y

reserving @> and <@ for future strict comparison operators.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2006-09-04 14:49:37 Re: [PATCHES] possible ecpg vpath build error
Previous Message Hans-Juergen Schoenig 2006-09-04 14:24:01 Planner estimates and cast operations ,...