Re: [HACKERS] @ versus ~, redux

[Michael Glaesemann]

On Sep 10, 2006, at 5:21 , Tom Lane wrote:

In the category of "egad", I found out that the tinterval datatype  
uses

<< for "contains"!  This is simply bizarre --- whether you approve of
the inet-like notation or not, surely the arrows are pointing the  
wrong
way.  Given that tinterval is deprecated and not even documented,  
maybe

this isn't worth fixing.  Any thoughts?


I'd say leave tinterval as it is. If it's ever updated to use the  
modern time types (rather than abstime), that would be a logical time  
to change it, it seems to me.


Michael Glaesemann
grzm seespotcode net



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

[ just when you thought it was safe to go back in the water ... ]

"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
>> But maybe we should just stick with @> and <@ as per the ltree precedent,
>> and not worry about leaving room for strict inclusion tests.

> +1

OK, nobody objected to that, so I guess we have consensus on the names.
I started looking through the code to see exactly what will be affected,
and here's what I find:

contrib/cube:
a @ b   contains
a ~ b   is contained by
contrib/intarray:
a @ b   contains
a ~ b   is contained by
contrib/hstore:
a @ b   contains
a ~ b   is contained by
contrib/ltree:
a @> b  ancestor or equal
a <@ b  descendant or equal
ltree also uses ~ and @ for "tree satisfies query", which is pretty close to
the core string types' usage of ~
ltree appears not to need changes

contrib/seg:
a @ b   contains
a ~ b   is contained by (misdocumented!)
contrib/tsearch2:
a @ b   contains
a ~ b   is contained by

Core operators:

 @(anyarray,anyarray) | arraycontains
 @(box,box)   | box_contained
 @(circle,circle) | circle_contained
 @(polygon,polygon)   | poly_contained
 ~(anyarray,anyarray) | arraycontained
 ~(box,box)   | box_contain
 ~(circle,circle) | circle_contain
 ~(polygon,polygon)   | poly_contain

I was pleased to find out that every one of the above ops is non-strict
containment (ie, equality yields 'true').  So at least we don't have
inconsistency on that point.

I also realized that there are several more core operators using @ and ~
for containment-like comparisons:

 @(lseg,box)  | on_sb
 @(lseg,line) | on_sl
 @(point,box) | on_pb
 @(point,circle)  | pt_contained_circle
 @(point,line)| on_pl
 @(point,lseg)| on_ps
 @(point,path)| on_ppath
 @(point,polygon) | pt_contained_poly
 ~(aclitem[],aclitem) | aclcontains
 ~(circle,point)  | circle_contain_pt
 ~(path,point)| path_contain_pt
 ~(polygon,point) | poly_contain_pt

Since these are cross-data-type comparisons, they are arguably not quite
the same animal as the operators listed earlier, which all compare two
objects of the same datatype.  I'm inclined to think that these ops
should be renamed too, but does anyone want to argue differently?

In the category of "egad", I found out that the tinterval datatype uses
<< for "contains"!  This is simply bizarre --- whether you approve of
the inet-like notation or not, surely the arrows are pointing the wrong
way.  Given that tinterval is deprecated and not even documented, maybe
this isn't worth fixing.  Any thoughts?

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Jeff Davis]

On Tue, 2006-09-05 at 23:00 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> 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 @>= yx contains or equals y
> >> x <=@ yx 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


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] @ versus ~, redux

[Bruce Momjian]

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   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] @ versus ~, redux

[Matteo Beccati]

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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] @ versus ~, redux

[Zeugswetter Andreas DCP SD]

> >> 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 @>= yx contains or equals y
> >> x <=@ yx 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

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Jeff Davis <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Jeff Davis]

On Mon, 2006-09-04 at 10:45 -0400, Tom Lane wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
> > On 2006-09-04, Tom Lane <[EMAIL PROTECTED]> 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




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Michael Glaesemann <[EMAIL PROTECTED]> writes:
> [ [EMAIL PROTECTED] 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  r1 /> r2r1 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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] @ versus ~, redux

[Michael Glaesemann]

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



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-09-04, Tom Lane <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Michael Glaesemann <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Matteo Beccati <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Matteo Beccati]

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

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Zeugswetter Andreas DCP SD]

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

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] @ versus ~, redux

[Gregory Stark]

Gregory Stark <[EMAIL PROTECTED]> writes:

> Matteo Beccati <[EMAIL PROTECTED]> 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


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] @ versus ~, redux

[Gregory Stark]

Matteo Beccati <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] @ versus ~, redux

[Matteo Beccati]

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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [HACKERS] @ versus ~, redux

[Andrew - Supernews]

On 2006-09-04, Tom Lane <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] @ versus ~, redux

[Michael Glaesemann]

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 >> r2r1 is strictly during r2, i.e., r1 is a strict subset of r2
r1 << r2r2 is strictly during r1, i.e., r2 is a strict subset of r1
<< and >> are meant to evoke the (strict) subset (⊂ or ⊂) and  
superset (⊃ or ⊃) 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 ⊆) and superset  
(⊇ or ⊇) 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 <> r2r1 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 <| r2r1 strictly meets r2, i.e.,  begin(r2) is next(end(r1))
r1 |> r2r2 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  r2r1 is after r2
The / is meant to evoke the fact that they are not abutting.

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


r1 @< r2r1 starts r2
r1 @> r2r2 starts r1
r1 >@ r2r1 finishes r2
r1 <@ r2r2 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.



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Andrew Dunstan <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] @ versus ~, redux

[Christopher Browne]

[EMAIL PROTECTED] (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 IIGGGH!!!


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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] @ versus ~, redux

[Andrew Dunstan]

Tom Lane wrote:

Andrew Dunstan <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Mark Dilger <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] @ versus ~, redux

[Mark Dilger]

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

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Andrew Dunstan <[EMAIL PROTECTED]> 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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] @ versus ~, redux

[jreich]

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



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] @ versus ~, redux

[Andrew Dunstan]

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 [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] @ versus ~, redux

[Tom Lane]

Oleg Bartunov  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

Re: [HACKERS] @ versus ~, redux

[Joshua D. Drake]

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/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] @ versus ~, redux

[Oleg Bartunov]

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@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] @ versus ~, redux

[Joshua D. Drake]

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/



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

[HACKERS] @ versus ~, redux

[Tom Lane]

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 [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings