Re: Wrong results in remove_useless_groupby_columns() - Mailing list pgsql-hackers

On Fri, May 8, 2026 at 11:57 AM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
> On Fri, 8 May 2026 at 05:46, Richard Guo <guofenglinux@gmail.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