[postgis-devel] Btree operators

[Komяpa]

Having counter-intuitive behaviour leads to realy sublte bugs that are
nearly impossible to debug.
SQL was meant as human-readable, things like this one really break the
perceprion of it as of English text and break expectations.

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.

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.

How about sorting by zig-zag-encoded coordinates?

Are there any showstoppers to implement this change, except of everyone has
to REINDEX?

чт, 7 апр. 2016 г. в 20:01, Rémi Cura <remi.cura at gmail.com>:

> Under the hood bounding box equality seems like a very counter intuitive
> behaviour.
>
> On the other hand, adding a "::text" or "::bytea"in the "distinct on" part
> does not feel like to much of a burden,
> although it is mighty ugly.
>
> Having a = operator with tolerance would be super useful, but I don't see
> how you could use it in a distinct query.
>
> Cheers,
> Rémi-C
>
> 2016-04-07 17:13 GMT+02:00 Sandro Santilli <strk at keybit.net>:
>
>> On Thu, Apr 07, 2016 at 03:06:56PM +0000, Komяpa wrote:
>> > чт, 7 апр. 2016 г. в 17:39, Paul Ramsey <pramsey at cleverelephant.ca>:
>> >
>> > > Speed is a benefit. Once you start down the road of = semantics, the
>> > > question of "which equals" looms large. Spatial equality?
>> > > Representational equality? Equality within a tolerance? Doing a string
>> > > compare is basically the only one that doesn't impose a surprising
>> > > cost, and it is, as you say, noisy.
>> >
>> > The equality that is the same as string compare would be a lot less
>> > surprising.
>> > It shouldn't be slower than bbox equality with recheck for the case when
>> > they're equal.
>>
>> We don't even need to convert to string, actually.
>> A memcmp call would be pretty fast.
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160411/c5e024e5/attachment.html>