| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Wrong results in remove_useless_groupby_columns() |
| Date: | 2026-05-08 08:15:04 |
| Message-ID: | CAMbWs4_xdLNrTbCZS1vqu8vG75sCkADcgvtBN=i1GtB8h8zOcA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, May 8, 2026 at 11:57 AM Ayush Tiwari
<ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
> On Fri, 8 May 2026 at 05:46, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> I plan to push and back-patch this shortly, as the code freeze for the
>> stable branches is just around the corner.
> I reviewed the patch and it looks good to me.
>
> The added opfamily and collation checks seem consistent with the uniqueness
> proof used in relation_has_unique_index_for(), and the tests cover both
> reported wrong-result cases.
>
> Applied the patch, ran tests, they passed.
Thanks for reviewing. I've committed this and back-patched it to v18.
I initially thought it needed to go back to v14, but it turns out to
be a v18 regression. Before v18, remove_useless_groupby_columns()
consulted only primary keys, whose enforcement index is required by
parse_utilcmd.c to use the default opclass and the column's declared
collation, so neither mismatch could arise.
- Richard
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tobias Bussmann | 2026-05-08 08:26:33 | Re: Broken build on macOS (Universal / Intel): cpuid instruction not available |
| Previous Message | Chao Li | 2026-05-08 08:14:40 | Fix wrong error message from pg_get_tablespace_ddl() |