[postgis-devel] [PostGIS] #253: Gist causes wrong result from ~=
PostGIS
trac at osgeo.org
Fri Oct 2 08:59:42 PDT 2009
#253: Gist causes wrong result from ~=
----------------------+-----------------------------------------------------
Reporter: nicklas | Owner: pramsey
Type: defect | Status: new
Priority: medium | Milestone: postgis 1.5.0
Component: postgis | Version: 1.4.X
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment (by kneufeld):
Mark, I agree that intuitively this does seem wrong. We currently don't
have an operator that tests just for bbox equality in gist_geometry_ops.
~= does seem to fit bill. I too think this is a bug in the original
behaviour.
I like the idea to change ~= to be just bbox equality and change ST_Equals
and ST_OrderingEquals appropriately as Regina suggested. (Yea, bbox
equality that uses gist indexes!)
Also, I agree that this a behavioural change and will have to wait till
2.0. I for one use ~= (currently meaning exact geometry equality) a lot.
Regina, on the topic of equality, doesn't the definition of
[http://trac.osgeo.org/postgis/browser/trunk/postgis/sqlmm.sql.in.c#L151
ST_OrderingEquals] have a redundent index lookup in there? the && could
probably be removed (at least until 2.0 when the def of ~= may change).
And it looks like
[http://trac.osgeo.org/postgis/browser/trunk/postgis/postgis.sql.in.c#L4529
ST_Equals] doesn't use any indexes. I was expecting to see "SELECT $1 &&
$2 AND _ST_Equals($1, $2)".
So, does this mean we need to put the RECHECK back in for
-- Kevin
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/253#comment:16>
PostGIS <http://trac.osgeo.org/postgis/>
PostGIS
More information about the postgis-devel
mailing list