[postgis-devel] [PostGIS] #253: Gist causes wrong result from ~=

[PostGIS]

#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