[postgis-devel] Death to Pointless Operators

[Paragon Corporation]

Mark, 

> IMO this is the wrong approach. The correct way to do this would be to
implement a new GiST opclass for the higher dimensions which is likely based
upon the contrib/cube operators and operator class. Then users specify at
build time what 
> dimensionality they want in the index and we can match an existing
operator class API/behaviour for migration purposes.

Do you mean at build time of the index?  I presume you don't mean build of
the code?

Paul and Mark,

I'm beginning to think that perhaps we do need two sets of operators.  The
problem is with the way you are doing it Paul -- If I understand correctly
is

&& now becomes a 3D overlap check.  Which would be fine with me -- except it
makes ST_Intersects a sorta 3D check.

Remember I asked whether we really need a ST_3DIntersects and can't we just
overload the ST_Intersects since if I have a #D geometry wouldn't I want a
3D check?

I lost that battle:  As Bitner wrote in
http://trac.osgeo.org/postgis/ticket/576

"Regina,

I prefer explicit 3D naming for functions that use the third dimension. The
underlying assumption right now is that all functions are 2D. A lot of
people just throw data into their dbs without even knowing that it has a
third dimension and they would be thrown quite off guard if all of the
sudden they started getting different results. If there is a SQL/MM standard
for naming, all the better.

David"

Thanks,
Regina