<div dir="ltr">Having counter-intuitive behaviour leads to realy sublte bugs that are nearly impossible to debug.<div>SQL was meant as human-readable, things like this one really break the perceprion of it as of English text and break expectations.</div><div><br></div><div>Distinct is (meant? felt?) to deduplicate identical records, that appeared possibly because of some join elsewhere in the flow (or for any other reason). For floating point numbers there, I don't really expect "nearly equals" behaviour, so ::bytea/memcmp-like comparsion for geometries seems sane in the case. </div><div><br></div><div>When I do SELECT DISTINCT geom, I want _distinct geometry_, not _geometry with distinct boxes_. For distinct boxes I'd write SELECT DISTINCT on (ST_Envelope(geom)) geom, and that's rather rare case. These two being swapped really require mind-twisting, and the more mind-twisting it requires the less people can use it.</div><div><br></div><div>How about sorting by zig-zag-encoded coordinates? </div><div><br></div><div>Are there any showstoppers to implement this change, except of everyone has to REINDEX?</div><div><br></div><div class="gmail_quote"><div dir="ltr">чт, 7 апр. 2016 г. в 20:01, Rémi Cura <<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Under the hood bounding box equality seems like a very counter intuitive behaviour.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">On the other hand, adding a "::text" or "::bytea"in the "distinct on" part does not feel like to much of a burden,<br></div><div class="gmail_default" style="font-family:monospace,monospace">although it is mighty ugly.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br>Having a = operator with tolerance would be super useful, but I don't see how you could use it in a distinct query.<br><br>Cheers,<br></div><div class="gmail_default" style="font-family:monospace,monospace">Rémi-C<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-07 17:13 GMT+02:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Apr 07, 2016 at 03:06:56PM +0000, Komяpa wrote:<br>
> чт, 7 апр. 2016 г. в 17:39, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>>:<br>
><br>
> > Speed is a benefit. Once you start down the road of = semantics, the<br>
> > question of "which equals" looms large. Spatial equality?<br>
> > Representational equality? Equality within a tolerance? Doing a string<br>
> > compare is basically the only one that doesn't impose a surprising<br>
> > cost, and it is, as you say, noisy.<br>
><br>
> The equality that is the same as string compare would be a lot less<br>
> surprising.<br>
> It shouldn't be slower than bbox equality with recheck for the case when<br>
> they're equal.<br>
<br>
</span>We don't even need to convert to string, actually.<br>
A memcmp call would be pretty fast.<br>
<br>
--strk;<br>
<div><div>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div></div>