[postgis-devel] Death to Pointless Operators

[Paul Ramsey]

I'm not sure that "overloading =" is going to be possible. We already
have a 'geometry = geometry' operator defined, in the btree opclass.
When I try to define another 'geometry = geometry' under gist, it says
there is already an '=' operator. And we need the '=' under btree if
we are to get 'group by' working the way we want, right? Or will any
'=' operator do for 'group by'?

P.

On Wed, Dec 22, 2010 at 6:32 AM, Paragon Corporation <lr at pcorp.us> wrote:
>
>> No, I was suggesting that we leave the existing index code in place and
>> add a second operator class so that the user can specify at build time
>> which type of index they want, e.g. based on contrib/cube:
>
> Huh.  You mean at compile time or build time of the index or install of
> postgis in the db?  -- I still don't get what you are saying?
> How many people compile their own postgis? What if I want two different
> behaviors in the same database or same server (if what you are suggesting is
> at compile time)?
>
> Don't operators have to work even when you don't have an index?
>
>> This gives a greatly reduced set of operators for multi-dimensional
>> indices, and allows the user to build a multi-dimensional index using
>> something like:
>
>> CREATE INDEX foo ON bar USING gist (baz gist_geometry_nd_ops);
> Don't I still have the problem of ST_Intersects sorta doing 3D checks when
> it shouldn't?
>
>
>> Also the thought that ST_Intersects may return a different answer if I
> have
>> a 2D vs.  3D index in place is even more disturbing.
>
>> That's a different issue though, no? I thought the plan was to follow
>> the ISO/MM spec convention of adding a 3D suffix to the function name if
>> it was 3D, e.g. you would use ST_Intersect3D() if you wanted a 3D
>> intersection? Otherwise we should stick to 2D.
>
> That's my point.  In my understanding MM says ST_Intersects only considers
> 2D, not 3D.  So we can't have a 3D short-circuit bbox call in there.
> Because then you get the mutant behavior where ST_Intersects would otherwise
> return true because the 2D bbx and the real 2D intersects are true,
> But now
>
> The _ST_Intersects never runs because your 3D box check returns false even
> though the 2Ds ACTUALLY intersect.
>
> So that's why I'm saying the only option it seems is
>
> &&& for 3D and ST_3DIntersects will use the &&& and ST_Intersects would use
> the && which we would still keep as a 2D box check.
>
> Note: I'm more concerned about the && case than anything else since so many
> functions we have rely on that.  I don't care much either way what we do
> with the other functions.
>
> I personally think our new bbox equality should be whatever the bbox is so =
> would be 2D for 2D geometries and 3D for 3D geometries -- which it sounds
> like that is what Paul already has in there.
>
> It also sounds to me like a big mess to maintain 2 sets of opclasses,
> admittedly  I know a lot less about this than you and Paul so I could be
> very mistaken.
>
> Thanks,
> Regina
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>