[postgis-devel] Death to Pointless Operators

Paul Ramsey pramsey at opengeo.org
Fri Dec 24 14:09:14 PST 2010


The default gserialized index is now 2d and uses the full set of old operators.

P

On Fri, Dec 24, 2010 at 1:30 PM, Paul Ramsey <pramsey at opengeo.org> wrote:
> 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
>>
>



More information about the postgis-devel mailing list