@ versus ~, redux

Awhile back I complained that while all the core geometric datatypes
use operator @ to mean "contained in" and operator ~ to mean "contains",
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php

There was some followup discussion generally agreeing that we ought to
get these things in sync, but then Andrew(at)supernews threw a monkey
wrench into the proceedings by suggesting we change to different names
entirely:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01263.php
That is not necessarily a bad idea, but I didn't want to get drawn
into a debate about exactly what alternative names to adopt, so I
dropped the problem for the time being.

I now find that the GIN patch has propagated the contrib meanings
of these operators into the core:
http://archives.postgresql.org/pgsql-general/2006-09/msg00087.php
and at this point I'm going to put my foot down and insist that
we do *something*. I won't hold still for fundamentally backward
meanings of the same operator name within the core datatypes.

I can see various things that we might consider doing:

1. Just flip the names of the two operators added by the GIN patch.

2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intarray is out
of step too ... are there others?).

3. Leave the existing op names as-is in core and contrib, but consider
them deprecated and add new ops with consistently-chosen names.
(The new ops introduced by GIN should only exist with the new names.)

#1 isn't doing anything towards solving the underlying problem.
#2 has got obvious backwards-compatibility issues for contrib users.
#3 may or may not be technically feasible (I'm not sure if we can
support multiple operators occupying the same slot in an opclass),
besides which choosing the names to use could degenerate to a flamewar.

Thoughts, votes, better ideas? The only option I'm *not* open to is
leaving HEAD as it stands.

regards, tom lane

> I can see various things that we might consider doing:
>
> 1. Just flip the names of the two operators added by the GIN patch.
>
> 2. #1 plus flip the names of the various contrib operators that are
> out of sync (Michael Fuhr points out that contrib/intarray is out
> of step too ... are there others?).
>
> 3. Leave the existing op names as-is in core and contrib, but consider
> them deprecated and add new ops with consistently-chosen names.
> (The new ops introduced by GIN should only exist with the new names.)
>
> #1 isn't doing anything towards solving the underlying problem.
> #2 has got obvious backwards-compatibility issues for contrib users.

+1 on #2 with the following caveat. When we publish the release notes,
we have a specific section that says:

Compatibility changes from previous releases. Which IMHO should be there
anyway as there are always compatibility issues from release to release.

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

On Sun, 3 Sep 2006, Joshua D. Drake wrote:

>
>> I can see various things that we might consider doing:
>>
>> 1. Just flip the names of the two operators added by the GIN patch.
>>
>> 2. #1 plus flip the names of the various contrib operators that are
>> out of sync (Michael Fuhr points out that contrib/intarray is out
>> of step too ... are there others?).
>>
>> 3. Leave the existing op names as-is in core and contrib, but consider
>> them deprecated and add new ops with consistently-chosen names.
>> (The new ops introduced by GIN should only exist with the new names.)

#3 looks good to me. Too many users. We should give them time for
upgrading. Probably, we need special chapter "To be obsoleted in the next
release" in Release notes.

>>
>> #1 isn't doing anything towards solving the underlying problem.
>> #2 has got obvious backwards-compatibility issues for contrib users.
>
> +1 on #2 with the following caveat. When we publish the release notes, we
> have a specific section that says:
>
> Compatibility changes from previous releases. Which IMHO should be there
> anyway as there are always compatibility issues from release to release.
>
> Joshua D. Drake
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

Oleg Bartunov wrote:
> On Sun, 3 Sep 2006, Joshua D. Drake wrote:
>
>>
>>> I can see various things that we might consider doing:
>>>
>>> 1. Just flip the names of the two operators added by the GIN patch.
>>>
>>> 2. #1 plus flip the names of the various contrib operators that are
>>> out of sync (Michael Fuhr points out that contrib/intarray is out
>>> of step too ... are there others?).
>>>
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>> them deprecated and add new ops with consistently-chosen names.
>>> (The new ops introduced by GIN should only exist with the new names.)
>
> #3 looks good to me. Too many users. We should give them time for
> upgrading. Probably, we need special chapter "To be obsoleted in the next
> release" in Release notes.

Users will have time to upgrade should they be responsible. Nobody in
their right might is going to upgrade to 8.2 on a production site the
day it is released.

They are going to test it with their code, and their work load. If it
takes them an extra day to implement query changes (or even an extra
month), good. It will serve them better in the long run.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>> them deprecated and add new ops with consistently-chosen names.
>>> (The new ops introduced by GIN should only exist with the new names.)

> #3 looks good to me. Too many users.

Not only that, but it'd be a serious problem for something like a SQL
script to be cross-version-compatible if we reverse the meanings of the
existing operators.

AFAIK all the operators in question exist only in GIST opclasses, so one
possible solution to the multiple-operators-per-slot problem is to
extend the opclasses --- ie, teach the gist_consistent methods to
support two different strategy numbers that do the same thing. Ugly
and tedious, but it'd preserve backward compatibility.

regards, tom lane

I also vote +1 for #3. Not only are there too many users, but simply
switching the sense of these operators will mean that code will still run,
but give incorrect answers and while it would be nice to think that all
client code has decent regression testing, this ain't the case.

If we are going to fix things so that all packages use the same sense, we
should slowly deprecate the current notation, and outright drop it for 8.2
or 8.3. What is the concensus: do it this release or next?

I also like the '@<' and '@>' notation as this gives a clear visual cue.

Josh Reich

> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
>>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>>> them deprecated and add new ops with consistently-chosen names.
>>>> (The new ops introduced by GIN should only exist with the new names.)
>
>> #3 looks good to me. Too many users.
>
> Not only that, but it'd be a serious problem for something like a SQL
> script to be cross-version-compatible if we reverse the meanings of the
> existing operators.
>
> AFAIK all the operators in question exist only in GIST opclasses, so one
> possible solution to the multiple-operators-per-slot problem is to
> extend the opclasses --- ie, teach the gist_consistent methods to
> support two different strategy numbers that do the same thing. Ugly
> and tedious, but it'd preserve backward compatibility.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

Tom Lane wrote:
> Awhile back I complained that while all the core geometric datatypes
> use operator @ to mean "contained in" and operator ~ to mean "contains",
> contrib/cube and contrib/seg switch the meanings:
> http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php
>
> There was some followup discussion generally agreeing that we ought to
> get these things in sync, but then Andrew(at)supernews threw a monkey
> wrench into the proceedings by suggesting we change to different names
> entirely:
> http://archives.postgresql.org/pgsql-hackers/2005-06/msg01263.php
> That is not necessarily a bad idea, but I didn't want to get drawn
> into a debate about exactly what alternative names to adopt, so I
> dropped the problem for the time being.
>
> I now find that the GIN patch has propagated the contrib meanings
> of these operators into the core:
> http://archives.postgresql.org/pgsql-general/2006-09/msg00087.php
> and at this point I'm going to put my foot down and insist that
> we do *something*. I won't hold still for fundamentally backward
> meanings of the same operator name within the core datatypes.
>
> I can see various things that we might consider doing:
>
> 1. Just flip the names of the two operators added by the GIN patch.
>
> 2. #1 plus flip the names of the various contrib operators that are
> out of sync (Michael Fuhr points out that contrib/intarray is out
> of step too ... are there others?).
>
> 3. Leave the existing op names as-is in core and contrib, but consider
> them deprecated and add new ops with consistently-chosen names.
> (The new ops introduced by GIN should only exist with the new names.)
>
> #1 isn't doing anything towards solving the underlying problem.
> #2 has got obvious backwards-compatibility issues for contrib users.
> #3 may or may not be technically feasible (I'm not sure if we can
> support multiple operators occupying the same slot in an opclass),
> besides which choosing the names to use could degenerate to a flamewar.
>
> Thoughts, votes, better ideas? The only option I'm *not* open to is
> leaving HEAD as it stands.
>
>
>
>

How about?:

4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
deprecate the operators for both contrib and core. Something more
visually like set ops would be ideal.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> How about?:
> 4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
> deprecate the operators for both contrib and core. Something more
> visually like set ops would be ideal.

If we're going to adopt new preferred names, I see no reason to support
the old confusing names for operators that have never existed before
8.2. There is no backward-compatibility argument to be made there.

regards, tom lane

Tom Lane wrote:

> I can see various things that we might consider doing:
>
> 1. Just flip the names of the two operators added by the GIN patch.
>
> 2. #1 plus flip the names of the various contrib operators that are
> out of sync (Michael Fuhr points out that contrib/intarray is out
> of step too ... are there others?).
>
> 3. Leave the existing op names as-is in core and contrib, but consider
> them deprecated and add new ops with consistently-chosen names.
> (The new ops introduced by GIN should only exist with the new names.)
>
> #1 isn't doing anything towards solving the underlying problem.
> #2 has got obvious backwards-compatibility issues for contrib users.
> #3 may or may not be technically feasible (I'm not sure if we can
> support multiple operators occupying the same slot in an opclass),
> besides which choosing the names to use could degenerate to a flamewar.

I suggest: #4 Standardize on new names and completely drop old naming
scheme, both in core and in contrib.

#2 is much too dangerous, because people may not recognize that their
code needs updating. #3 introduces new code in core that has no other
legitimate purpose (or does someone see a reason why this is generally
useful?)

#4 would force people to notice that their code needs updating, which is
far safer than hoping people will notice.

mark

Mark Dilger <pgsql(at)markdilger(dot)com> writes:
> I suggest: #4 Standardize on new names and completely drop old naming
> scheme, both in core and in contrib.

Deliberately breaking code that has always worked doesn't sound very
appetizing to me. If there were simply no good alternative to it, then
maybe, but generally we have higher regard for backwards compatibility
than to do it just because it's neater.

I agree with planning to arrive at state #4 after a transitional release
or three, but to do it now with no warning will simply bring us visits
from angry pitchfork-bearing villagers...

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> How about?:
>> 4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
>> deprecate the operators for both contrib and core. Something more
>> visually like set ops would be ideal.
>>
>
> If we're going to adopt new preferred names, I see no reason to support
> the old confusing names for operators that have never existed before
> 8.2. There is no backward-compatibility argument to be made there.
>
>
>

You're right. I misread your original proposal. I vote for #3.

cheers

andrew

tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) wrote:
> I agree with planning to arrive at state #4 after a transitional release
> or three, but to do it now with no warning will simply bring us visits
> from angry pitchfork-bearing villagers...

But then we can send out Trogdor...

Trogdor!
Trogdor!

Burninating the countryside,
Burninating the peasants,
Burninating all the people and the thatched-roof cottages
Thatched-roof cottages!

And the Trogdor comes in the NNNNNNNNIIIIIIIIIIIIIIGGGHHHHHHHHHHHHHHHHHHHHH!!!
<http://en.wikipedia.org/wiki/Trogdor>

Sorry, but there's something about fighting pitchforks with fire...
--
select 'cbbrowne' || '@' || 'acm.org';
http://cbbrowne.com/info/postgresql.html
"Once you accept that the world is a giant computer run by white mice,
all other movies fade into insignificance." -- Mutsumi Takahashi

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>> them deprecated and add new ops with consistently-chosen names.
>>> (The new ops introduced by GIN should only exist with the new names.)

> You're right. I misread your original proposal. I vote for #3.

OK, so if everyone is leaning to #3, the name game remains to be played.
Do we all agree on this:

"x @> y" means "x contains y"
"x @< y" means "x is contained in y"

Are we all prepared to sign a solemn oath to commit hara-kiri if we
invent a new datatype that gets this wrong? No? Maybe these still
aren't obvious enough.

BTW, even with the gist_consistent hack there's still a bit of a
technical problem: pg_operator can represent the knowledge that @> and
@< are commutators, and that @ and ~ are commutators, but not (at the
same time) that @> and @ are commutators. This is not a fatal objection
but it's a tad annoying --- I think there are cases where the planner
would miss possible optimizations if it can't see this. Anybody see a
suitably low-cost fix? Does it not matter if every GIST opclass has
mappings for both operator pairs?

regards, tom lane

On Sep 4, 2006, at 12:44 , Tom Lane wrote:

> OK, so if everyone is leaning to #3, the name game remains to be
> played.
> Do we all agree on this:
>
> "x @> y" means "x contains y"
> "x @< y" means "x is contained in y"
>
> Are we all prepared to sign a solemn oath to commit hara-kiri if we
> invent a new datatype that gets this wrong? No? Maybe these still
> aren't obvious enough.

When I've been working on range/interval stuff, I tried to come up
with a self-consistent set of operator symbols for the Allen
operators, which includes the "contains" and "is contained in" pair.
Here's what I came up with.

Where r1 and r2 are ranges

r1 >> r2 r1 is strictly during r2, i.e., r1 is a strict subset of r2
r1 << r2 r2 is strictly during r1, i.e., r2 is a strict subset of r1
<< and >> are meant to evoke the (strict) subset (⊂ or &sub;) and
superset (⊃ or &sup;) operators.

r1 <<= r2 r1 is a superset of r2
r1 =>> r2 r1 is a subset of r2

<<= and =>> are mean to evoke the subset (⊆ or &sube;) and superset
(⊇ or &supe;) operators.

Assuming the meaning of contains and is contained in is inclusive
(rather than strict), then we'd have

a <<= b : a contains b
a =>> b : a is contained by b

I've included the other Allen operators at the bottom for completeness.

Michael Glaesemann
grzm seespotcode net

r1 = r2 r1 equals r2
r1 <> r2 r1 does not equal r2
For the following, the < or > indicates the relative position of the
two ranges if they were depicted on an line that increases from left
to right.

r1 <| r2 r1 strictly meets r2, i.e., begin(r2) is next(end(r1))
r1 |> r2 r2 strictly meets r2, i.e., begin(r1) is next(end(r2))
The | is meant to evoke the meeting point of r1 and r2. They don't
overlap, they are just abutting. The < or > "points" to the direction
the of the range it points to relative to the other range, i.e., r1
is to the left of r2 on an line that increases from left to right.

r1 </ r2 r1 is before r2
r1 /> r2 r1 is after r2
The / is meant to evoke the fact that they are not abutting.

r1 <& r2 r1 strictly overlaps r2
r1 &> r2 r2 strictly overlaps r1
The & is meant to evoke "and", in that there is something the two
ranges share.

r1 @< r2 r1 starts r2
r1 @> r2 r2 starts r1
r1 >@ r2 r1 finishes r2
r1 <@ r2 r2 finishes r1
The @ is meant to indicate the point where the two ranges share a
begin or end point. E.g., for r1 @< r2, r1 and r2 start together, and
end(r1) < end(r2). For r1 <@ r2, begin(r1) < begin(r2), but they
share the same end point.

Tom Lane ha scritto:
> OK, so if everyone is leaning to #3, the name game remains to be played.
> Do we all agree on this:
>
> "x @> y" means "x contains y"
> "x @< y" means "x is contained in y"
>
> Are we all prepared to sign a solemn oath to commit hara-kiri if we
> invent a new datatype that gets this wrong? No? Maybe these still
> aren't obvious enough.

Does this mean that also contrib/ltree operators will likely change for
consistency?

ltree @> ltree
- returns TRUE if left argument is an ancestor of right argument
(or equal).
ltree <@ ltree
- returns TRUE if left argument is a descendant of right argument
(or equal).

Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

On 2006-09-04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> OK, so if everyone is leaning to #3, the name game remains to be played.
> 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"

(obviously these don't all necessarily make sense for all types)

These have the advantage of resembling set notation more closely and being
in use in one existing core type.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Matteo Beccati <php(at)beccati(dot)com> writes:

> Tom Lane ha scritto:
>> OK, so if everyone is leaning to #3, the name game remains to be played.
>> Do we all agree on this:
>>
>> "x @> y" means "x contains y"
>> "x @< y" means "x is contained in y"
>>
>> Are we all prepared to sign a solemn oath to commit hara-kiri if we
>> invent a new datatype that gets this wrong? No? Maybe these still
>> aren't obvious enough.
>
> Does this mean that also contrib/ltree operators will likely change for
> consistency?
>
> ltree @> ltree
> - returns TRUE if left argument is an ancestor of right argument (or
> equal).
> ltree <@ ltree
> - returns TRUE if left argument is a descendant of right argument (or
> equal).

If you consider ltree entries to be sets containing all their children then
those sound consistent.

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

Gregory Stark <stark(at)enterprisedb(dot)com> writes:

> Matteo Beccati <php(at)beccati(dot)com> writes:
>
> > Tom Lane ha scritto:
> > >
> > > "x @< y" means "x is contained in y"
> >
> > ltree <@ ltree
>
> If you consider ltree entries to be sets containing all their children then
> those sound consistent.

Oops, sorry for the noise.

--
greg

> > > > "x @< y" means "x is contained in y"
> > >
> > > ltree <@ ltree
> >
> > If you consider ltree entries to be sets containing all their
children
> > then those sound consistent.

Now we get to decide whether "<@" was better than the now proposed "@<"
:-)
I like <@. (or we stay clear by using the inet ops)

Andreas

Matteo Beccati <php(at)beccati(dot)com> writes:
> Tom Lane ha scritto:
>> OK, so if everyone is leaning to #3, the name game remains to be played.
>> Do we all agree on this:
>>
>> "x @> y" means "x contains y"
>> "x @< y" means "x is contained in y"

> Does this mean that also contrib/ltree operators will likely change for
> consistency?

Oh, I hadn't noticed that ltree spells it "<@" rather than "@<". I'd be
inclined to stick with the ltree precedent.

regards, tom lane

Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> Assuming the meaning of contains and is contained in is inclusive
> (rather than strict), then we'd have

> a <<= b : a contains b
> a =>> b : a is contained by b

I don't think we can consider that, because we already have << and >>
operators meaning "is left of", "is right of" for (some of) the affected
datatypes. We'd have to start renaming those too, and that very rapidly
turns into a mess.

regards, tom lane

Hi,

> Oh, I hadn't noticed that ltree spells it "<@" rather than "@<". I'd be
> inclined to stick with the ltree precedent.

This was exactly my implicit proposal :)

Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

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

On Sep 4, 2006, at 23:45 , Tom Lane wrote:

>> 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"

(I'd be fine with Andrew's versions. I probably picked them up from
his ip4r code, now that I think about it.)

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

Well, I do have suggestions for those, too :)

r1 </ r2 r1 is to the left of r2 (r1 is before r2)
r1 /> r2 r1 is to the right of r2 (r1 is after r2)

> Also, if we wanted to implement both strict and nonstrict containment
> operators, we're suddenly talking about adding code not only catalog
> entries.

AFAICT, both Andrew and I only include the strict/non-strict versions
because it's useful to make the distinction for our use cases. If the
geometric inclusion operators don't make the distinction, I'd assume
they're inclusive, as that's the more common understanding. Just use
the one that applies and leave out the other. Granted, it means two
pairs of reassignments (the to the left/right of and the subset/
superset), but if we're breaking it, one more pair isn't that big of
a deal. And it leaves @ to mean something else.

Michael Glaesemann
grzm seespotcode net

Michael Glaesemann <grzm(at)seespotcode(dot)net> writes:
> [ andrew(at)supernews wrote: ]
>>> 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"

> (I'd be fine with Andrew's versions. I probably picked them up from
> his ip4r code, now that I think about it.)

Actually, I have another objection to those names, which is that they
look too much like C bit-shift operators to me ...

> Well, I do have suggestions for those, too :)

> r1 </ r2 r1 is to the left of r2 (r1 is before r2)
> r1 /> r2 r1 is to the right of r2 (r1 is after r2)

And do you have extensions of those for "is below"/"is above"?

This way madness lies. Let's sync the containment operators, not
start relabeling every operator in sight.

regards, tom lane

On Mon, 2006-09-04 at 10:45 -0400, Tom Lane wrote:
> 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"
>
> 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.
>

At first glace, it seems more intuitive to me to do:

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

It seems more natural to me because the operators are symmetrical. Am I
missing the mnemonic value of your form?

Regards,
Jeff Davis

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Mon, 2006-09-04 at 10:45 -0400, Tom Lane wrote:
>> 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.

> At first glace, it seems more intuitive to me to do:

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

Hm, I've never seen anyone spell "less than or equal to" as "=<",
so I'm not sure where you derive "=<@" from? Not saying "no", but
the other seems clearer to me.

regards, tom lane

> >> 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.
>
> > At first glace, it seems more intuitive to me to do:
>
> > x @>= y x contains or equals y
> > x =<@ y y is contained in or equals y
>
> Hm, I've never seen anyone spell "less than or equal to" as
> "=<", so I'm not sure where you derive "=<@" from? Not
> saying "no", but the other seems clearer to me.

Yes, but to me too =<@ seems more natural since we started with @> and
<@.
Tom, your argument would more match your original @> and @<, but then it

would imply @>= and @<=, imho.

Andreas

Tom Lane wrote:
> 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.

Since the choice of @> and <@ comes from current ltree operators I'd
like to point out that they are non-strict for ltree, and this could add
a little bit of inconsistence.

Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

"Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> Hm, I've never seen anyone spell "less than or equal to" as
>> "=<", so I'm not sure where you derive "=<@" from? Not
>> saying "no", but the other seems clearer to me.

> Yes, but to me too =<@ seems more natural since we started with @> and <@.
> Tom, your argument would more match your original @> and @<, but then it
> would imply @>= and @<=, imho.

Well, I'm reading it as "a comparison operator with @ plastered on the
side of the larger object", not a mirror-image thing. But maybe we
should just stick with @> and <@ as per the ltree precedent, and not
worry about leaving room for strict inclusion tests.

regards, tom lane

Zeugswetter Andreas DCP SD wrote:
>
> > >> 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.
> >
> > > At first glace, it seems more intuitive to me to do:
> >
> > > x @>= y x contains or equals y
> > > x =<@ y y is contained in or equals y
> >
> > Hm, I've never seen anyone spell "less than or equal to" as
> > "=<", so I'm not sure where you derive "=<@" from? Not
> > saying "no", but the other seems clearer to me.
>
> Yes, but to me too =<@ seems more natural since we started with @> and
> <@.
> Tom, your argument would more match your original @> and @<, but then it
>
> would imply @>= and @<=, imho.

Doesn't "=<@" represent the ship from the BASIC version of the Star Trek
game from the 70's? :-)

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, 2006-09-05 at 23:00 -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > On Mon, 2006-09-04 at 10:45 -0400, Tom Lane wrote:
> >> 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.
>
> > At first glace, it seems more intuitive to me to do:
>
> > x @>= y x contains or equals y
> > x =<@ y y is contained in or equals y
>
> Hm, I've never seen anyone spell "less than or equal to" as "=<",
> so I'm not sure where you derive "=<@" from? Not saying "no", but
> the other seems clearer to me.

Initially it seemed strange to me because the @ switches sides but the
operator is not symmetrical.

I see what you mean. Standard <= and >= syntax, with an @ on the side of
the container. Now I'll be able to remember it at least, so I'm really
fine with anything.

Regards,
Jeff Davis