Re: Wrong results in remove_useless_groupby_columns()

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

In response to

Browse pgsql-hackers by date

  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()