Re: [HACKERS] @ versus ~, redux

2006-09-09 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-09 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-06 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-06 Thread 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 @

Re: [HACKERS] @ versus ~, redux

2006-09-06 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-06 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-06 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-05 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-05 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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.

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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)

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-04 Thread 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

[HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread Tom Lane
Oleg Bartunov oleg@sai.msu.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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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,

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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

Re: [HACKERS] @ versus ~, redux

2006-09-03 Thread 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