Ah yes, you're right. For some reason I thought the bytea would
silently convert to a geometry object, but, yes, looking at it rather
than skim reading :), you're comparing two bytea objects (bytea A =
bytea B).
And interesting idea with the undefined question approach. I suppose we
could add a validity check to ST_Equals for this purpose and to keep if
fast, change ST_Equals to the typical sql wrapper so it can use any
indexes via && (I don't know why this is not there now anyway). But
then, by rights, the same argument holds for the other functions as
well. ST_Union, ST_Area, and a plethora of others should produce
undefined results on undefined input. hmmm. Where to draw the line, eh?
In the end, I agree that this will add unnecessary overhead. Leave it
for the users.
Cheers,
Kevin
Obe, Regina wrote:
Kevin,
We should clarify this in the docs. Yes I was thinking it wasn't really
a bug and kind of open to interpretation when you give it something
invalid. I was actually thinking it should behave more like the SQL
constructs
SELECT NULL IS NULL As istrue, NULL = NULL As isunknown
basically an undefined question should return an undefined answer. Not
a false, but I suppose that may add unnecessary overhead and potentially
break other things.
Regarding the ST_AsBinary(geom1) = ST_AsBinary(geom2) -- I beg to
differ -- although geom1 = geom2 probably does do a bounding box check.
I think the ST_AsBinary would force a bit by bit compare I think
(actually I have a feeling that is what ST_OrderingEquals really does
though haven't looked at the code for that).
Look at this example
SELECT ST_AsBinary(ST_Collect('POINT(1 1)', 'POINT(2 1)')) =
ST_AsBinary(ST_Collect('POINT(2 1)', 'POINT(1 1)')) As binaryequal,
ST_Collect('POINT(1 1)', 'POINT(2 1)') = ST_Collect('POINT(2 1)',
'POINT(1 1)');
Thanks,
Regina
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
