Re: @ versus ~, redux

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: @ versus ~, redux
Дата
Msg-id 23762.1157381155@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: @ versus ~, redux  (Andrew - Supernews <andrew+nonews@supernews.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Hans-Juergen Schoenig
Дата:
Сообщение: Planner estimates and cast operations ,...
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: [PATCHES] possible ecpg vpath build error