Re: Requesting advanced Group By support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Arun Kumar <vak(dot)king(at)outlook(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Requesting advanced Group By support
Date: 2018-10-10 17:50:24
Message-ID: 16807.1539193824@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> So, which part of this supposedly does not work in PostgreSQL?

> The part where it infers that b.sno is unique based solely on it having
> been equated to a.sno.

Oh, wait a second: such an inference is actually *wrong* in the general
case, or at least underdetermined. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Joseph Krogh 2018-10-10 17:56:49 Sv: Re: Requesting advanced Group By support
Previous Message Tom Lane 2018-10-10 17:37:40 Re: Requesting advanced Group By support