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
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 ,... |