[postgis-devel] Death to Pointless Operators
Mark Cave-Ayland
mark.cave-ayland at siriusit.co.uk
Wed Dec 22 02:05:21 PST 2010
Paragon Corporation wrote:
> Mark,
> Are you saying you want people to define an index before hand and have the
> index determine how the operation behaves? What if there is no index? What
> then.
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:
CREATE OPERATOR CLASS gist_geometry_nd_ops
DFOR TYPE geometry USING gist AS
OPERATOR 3 && ,
OPERATOR 6 = ,
OPERATOR 7 @> ,
OPERATOR 8 <@ ,
OPERATOR 13 @ ,
OPERATOR 14 ~ ,
FUNCTION 1 geometry_nd_consistent (internal, cube,
int, oid, internal),
FUNCTION 2 geometry_nd_union (internal, internal),
FUNCTION 3 geometry_nd_compress (internal),
FUNCTION 4 geometry_nd_decompress (internal),
FUNCTION 5 geometry_nd_penalty (internal,
internal, internal),
FUNCTION 6 geometry_nd_picksplit (internal, internal),
FUNCTION 7 geometry_nd_same (cube, cube, internal);
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);
> 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.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
More information about the postgis-devel
mailing list