[postgis-devel] Should EMPTY be spatially equal to self ?

[Sandro Santilli]

On Thu, Jan 12, 2012 at 07:09:22PM -0500, Paragon Corporation wrote:
> 
> > I don't know how many people are using ST_Equals in a 
> > supposedly fast query.
> > Anyway, I didnt' research on why ~= isn't index bound, did you ?
> > 
> > --strk;
> It's because we remarked it out and I think the reason we remarked it out in
> 2.0 is we don't want people using it and we should probably deprecate it
> completely. So we removed it out of the index ops so that we can safely drop
> it later without requiring people to relaod/reindex their data.
> 
> ~= has a long history of being very confusing
> 
> 1) It's meaning is different from the way PostgreSQL built-in types use it
> e. similar types like postgresl built in goemetric and pgSphere
> use it for something different.  I forget the exact meaning.

~= for geometric built-in types is documented to mean the same as our ST_Equals:
http://www.postgresql.org/docs/8.4/interactive/functions-geometry.html

But seems to be to be bounding box equality:

=$ select polygon '((0,0),(0,10),(10,10))' && polygon '((5,5),(10,5))';
 t

> 2) Pre-1.4. it did an exact geometric match -- essentially meaning the same
> thing as  ST_OrderingEquals but when we took out the RECHECK
> that changed and it became a bounding box equality basically the same as =
> (except = is only indexable with a btree index and we needed
> to put it = against btree because it gets used in ORDER BY, GROUP BY
> 3) So what happened is since our upgrade script can't drop operators (index
> ones at least can't remember the others) we had an ugly situation where:
> 
> If you started with 1.4 your ~= meant bounding box equality
> If you started with a version prior to 1.4 and upgraded to 1.4+, your ~=
> meant geometric equality

Well, now we are moving to 2.0 so a dump/reload is required and we can feel
free to assume the operator will be for everyone the way we'll set it to be.

I think keeping ~= for bounding box equality is fine.
It's even mnemonically useful: "about equal".

> So in the end we said -- we needed to come up with another opertor that is
> gist indexable that means
> bounding box equality. And = was out because its already used by btree.

I'd avoid adding more complexity.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html