From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Vik Fearing <vik(at)postgresfriends(dot)org>, Georgios Kokolatos <gkokolatos(at)protonmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Erik Rijkers <er(at)xs4all(dot)nl> |
Subject: | Re: GROUP BY DISTINCT |
Date: | 2021-03-12 23:33:36 |
Message-ID: | b95ee556-c527-04b8-6cae-f55950dde94b@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Hi Vik,
The patch seems quite ready, I have just two comments.
1) Shouldn't this add another <indexterm> for DISTINCT, somewhere in the
documentation? Now the index points just to the SELECT DISTINCT part.
2) The part in gram.y that wraps/unwraps the boolean flag as an integer,
in order to stash it in the group lists is rather ugly, IMHO. It forces
all the places handling the list to be aware of this (there are not
many, but still ...). And there are no other places doing (bool) intVal
so it's not like there's a precedent for this.
I think the clean solution is to make group_clause produce a struct with
two fields, and just use that. Not sure how invasive that will be
outside gram.y, though.
Also, the all_or_distinct vs. distinct_or_all seems a bit error-prone. I
wonder if we can come up with some clearer names, describing the context
of those types.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Pantelis Theodosiou | 2021-03-13 01:03:19 | Fwd: GROUP BY DISTINCT |
Previous Message | Tom Lane | 2021-03-12 15:03:17 | Re: Invalid idle_in_transaction_session_timeout data type |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-03-13 00:34:16 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
Previous Message | Mark Dilger | 2021-03-12 23:32:03 | Re: pg_amcheck contrib application |