[postgis-devel] Death to Pointless Operators

[Paragon Corporation]

> 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