[ 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
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
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
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 @
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
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
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
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
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
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
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
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
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
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.
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
[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
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
32 matches
Mail list logo