Обсуждение: @ 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@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/intarrayis 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-chosennames. (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 solutionssince 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@sai.msu.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 solutionssince 1997 http://www.commandprompt.com/
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 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
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@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
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@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 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 >
Andrew Dunstan <andrew@dunslane.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@markdilger.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@dunslane.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@sss.pgh.pa.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@dunslane.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 ⊂) 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 <> 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.
On 2006-09-04, Tom Lane <tgl@sss.pgh.pa.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 containedin 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
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
Matteo Beccati <php@beccati.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@enterprisedb.com> writes: > Matteo Beccati <php@beccati.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
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
Matteo Beccati <php@beccati.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@seespotcode.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
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
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@seespotcode.net> writes: > [ andrew@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@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" > > 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 yx =<@ 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@j-davis.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@spardat.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@momjian.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@j-davis.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
[ just when you thought it was safe to go back in the water ... ] "Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> 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 containsa ~ b is contained by contrib/intarray:a @ b containsa ~ b is contained by contrib/hstore:a @ b containsa ~ b is contained by contrib/ltree:a @> b ancestor or equala <@ 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 containsa ~ b is contained by (misdocumented!) contrib/tsearch2:a @ b containsa ~ 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
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