Re: Requesting advanced Group By support

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,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:59:29
Message-ID: 31E6FC56-F21C-4F03-8666-F12F51FD2131@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On October 10, 2018 10:37:40 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> On 10/09/2018 03:10 PM, Arun Kumar wrote:
>>> *SELECT a.sno,b.sno,a.name,b.location FROM Name AS a JOIN Location
>AS b
>>> ON a.sno=b.sno GROUP BY a.sno,b.location *
>>>
>>> In this case, a.sno is a primary key so no need to include a.name in
>
>>> GROUP By as it would be identified by the primary key and then for
>b.sno
>>> which is again equated with a.sno (primary key) so no need to add
>this
>>> as well but for b.location, we need to add it in GROUP BY or we
>should
>>> use any aggregate function over this column to avoid error.
>
>> 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.

Isn't the spec compliant thing that's missing dealing with unique not null?

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Responses

Browse pgsql-hackers by date

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