Re: [HACKERS] Fixing r-tree semantics

2005-06-27 Thread Tom Lane
Bruno Wolff III <[EMAIL PROTECTED]> writes: > I seem to remember there being a problem if <, <=, > and >= operators > didn't exist and doing some operations (distinct or group by?) that > required sorting the data type. I am not sure that you are suggesting > that these operators be removed, No, I

Re: [HACKERS] Fixing r-tree semantics

2005-06-27 Thread Bruno Wolff III
On Sun, Jun 26, 2005 at 09:52:03 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: > > Now that the module uses GIST instead of r-tree, there's no very strong > reason why it should provide these operators at all. I propose removing > all of << >> &< &> from contrib/cube, leaving only the four > n-dim

Re: [HACKERS] Fixing r-tree semantics

2005-06-26 Thread Tom Lane
I wrote: > Andrew - Supernews <[EMAIL PROTECTED]> writes: >> Notice also that contrib/seg and contrib/cube have their own, and >> incompatible, idea of what the semantics of &< and &> should be. > Um. Not sure what to do about these ... any opinions? Having looked at this, I propose the followin

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread Mark Cave-Ayland
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 24 June 2005 14:27 > To: Mark Cave-Ayland (External) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; oleg@sai.msu.su; > pgsql-hackers@postgresql.org; 'PostGIS Development Discussion' > Subject: Re: Fixing r-tree semantic

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread William White
Tom Lane wrote: However, given that the behavior has been broken since the rtree code was written and nobody noticed except bwhite, I think it's pretty low-priority to back-patch. Well, leave it to me to find the obscure bugs in other people's code, and miss the blatant ones in my own. It's

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread Tom Lane
"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > The operators I went for were as follows: > A &<| B - true if A's bounding box overlaps or is below B's bounding > box > A |&> B - true if B's bounding box overlaps or is above B's bounding > box > A <<| B - true if A's bounding bo

Re: [HACKERS] Fixing r-tree semantics

2005-06-24 Thread Mark Cave-Ayland
Hi Tom, > What needs more discussion is that it seems to me to make sense to extend the standard > opclasses to handle the four Y-direction operators comparable to the X-direction > operators that are already there, that is "above", "below", "overabove", and > "overbelow". As part of PostGIS (

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Oleg Bartunov
On Thu, 23 Jun 2005, Tom Lane wrote: both directions (X and Y) for 1-D inquiries. The same problems exist in the contrib/rtree_gist implementation, because it just copied the r-tree logic without inquiring too closely into it :-( you're right, it was the beginning of our GiST experiments. Lat

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Bruce Momjian
FYI, TODO has: * Fix incorrect rtree results due to wrong assumptions about "over" operator semantics [rtree] --- Tom Lane wrote: > Hmmm ... just when you thought it was safe to go back in the water ... >

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Tom Lane
Hmmm ... just when you thought it was safe to go back in the water ... I was only looking closely at the "box" case earlier today, assuming that the polygon code was set up identically. Well, it isn't. In particular it appears that the poly_overleft and poly_overright definitions are different f

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Tom Lane
Andrew - Supernews <[EMAIL PROTECTED]> writes: > On 2005-06-23, Tom Lane <[EMAIL PROTECTED]> wrote: >> I looked into the r-tree breakage discussed in this thread: >> http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php > See also http://archives.postgresql.org/pgsql-bugs/2005-01/msg00

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Tom Lane
Michael Fuhr <[EMAIL PROTECTED]> writes: > On Thu, Jun 23, 2005 at 05:59:25PM -0400, Tom Lane wrote: >> Fixing the existing operators seems relatively straightforward; there will >> need to be some extension to rtstrat.c to represent "NOT this operator" >> as well as "this operator", but that's not

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Michael Fuhr
On Thu, Jun 23, 2005 at 05:59:25PM -0400, Tom Lane wrote: > > Fixing the existing operators seems relatively straightforward; there will > need to be some extension to rtstrat.c to represent "NOT this operator" > as well as "this operator", but that's not hard. I plan to do this, and > make the co

Re: [HACKERS] Fixing r-tree semantics

2005-06-23 Thread Andrew - Supernews
On 2005-06-23, Tom Lane <[EMAIL PROTECTED]> wrote: > I looked into the r-tree breakage discussed in this thread: > http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php See also http://archives.postgresql.org/pgsql-bugs/2005-01/msg00328.php in which I made most of the same points. Not

[HACKERS] Fixing r-tree semantics

2005-06-23 Thread Tom Lane
I looked into the r-tree breakage discussed in this thread: http://archives.postgresql.org/pgsql-general/2004-03/msg01135.php The executive summary: r-tree index opclasses contain four two-dimensional operators, which behave correctly, and four one-dimensional operators which do not. There is a b