[postgis-users] problem "st_equals".

[Kevin Neufeld]

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
>