| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Kohei KaiGai <kaigai(at)heterodb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Using non-grouping-keys at HAVING clause |
| Date: | 2023-09-08 10:07:52 |
| Message-ID: | 181d12be-302e-c05b-7320-3e700ae9a554@postgresfriends.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/8/23 09:42, Kohei KaiGai wrote:
> Hello,
>
> I got a trouble report here:
> https://github.com/heterodb/pg-strom/issues/636
>
> It says that PG-Strom raised an error when the HAVING clause used
> non-grouping-keys,
> even though the vanilla PostgreSQL successfully processed the query.
>
> SELECT MAX(c0) FROM t0 GROUP BY t0.c1 HAVING t0.c0<MIN(t0.c0);
>
> However, I'm not certain what is the right behavior here.
> The "c0" column does not appear in the GROUP BY clause, thus we cannot
> know its individual
> values after the group-by stage, right?
Wrong. c1 is the primary key and so c0 is functionally dependent on it.
Grouping by the PK is equivalent to grouping by all of the columns in
the table.
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-09-08 10:28:29 | Re: [PoC] pg_upgrade: allow to upgrade publisher node |
| Previous Message | Jelte Fennema | 2023-09-08 09:54:58 | Re: Support prepared statement invalidation when result types change |