On Wed, Oct 10, 2018 at 1:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It fails in cases where the data type
> considers distinguishable values to be "equal", as for example zero vs.
> minus zero in IEEE floats, or numeric values with varying numbers of
> trailing zeroes, or citext, etc. So for example if the sno columns are
> type citext, we can be sure that a.sno does not contain both 'X' and 'x',
> because the pkey would forbid it. But if it contains 'X', while b.sno
> contains both 'X' and 'x', then (if we allowed this case) it'd be
> indeterminate which b.sno value is returned by the GROUP BY. One might or
> might not consider that OK for a particular application, but I don't think
> the parser should just assume for you that it is.
Since this is approximately the 437,253rd time this problem has come
up, and since even reasonably experienced hackers often get confused
about it or (ahem) momentarily forget about the problem, it is really
well paste time to find some way of labeling operator classes or
families or individual operators to indicate whether or not they are
testing precisely the exactly-the-same property.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
