Re: @ versus ~, redux - Mailing list pgsql-hackers

From Tom Lane
Subject Re: @ versus ~, redux
Date
Msg-id 23762.1157381155@sss.pgh.pa.us
Whole thread Raw
In response to Re: @ versus ~, redux  (Andrew - Supernews <andrew+nonews@supernews.com>)
Responses Re: @ versus ~, redux  (Michael Glaesemann <grzm@seespotcode.net>)
Re: @ versus ~, redux  (Jeff Davis <pgsql@j-davis.com>)
Re: @ versus ~, redux  (Matteo Beccati <php@beccati.com>)
List pgsql-hackers
Andrew - Supernews <andrew+nonews@supernews.com> writes:
> On 2006-09-04, Tom Lane <tgl@sss.pgh.pa.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 yx <=@ y        x is contained in or equals y

reserving @> and <@ for future strict comparison operators.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hans-Juergen Schoenig
Date:
Subject: Planner estimates and cast operations ,...
Next
From: Michael Meskes
Date:
Subject: Re: [PATCHES] possible ecpg vpath build error