Re: BUG #19633: Unexpected results of IN (subquery) with a non-deterministic collation

On Fri, Sep 11, 2026 at 8:06 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Fri, Sep 11, 2026 at 4:03 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> >
> > On Fri, Sep 11, 2026 at 6:54 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > > I also like idea of usage of enable_sort all the version in this case.
> > > This would simplify backpatching and reduce divergence between
> > > versions.
> >
> > I believe one of the goals of commit e01b23b84 is replacing
> > enable_sort with enable_groupagg in tests going forward where that's
> > the real intent. Re-introducing enable_sort here seems to go against
> > that goal.
> >
> > > I plan to push this and backpatch through 14, adjusting the expected
> > > file per branch along the lines you described.
> >
> > Also I don't understand why v5 is still creating new tables rather
> > than using existing tables in the tests.
>
> Sorry, I accidentally used the wrong branch to generate the patch.
> Please, check the attached version: it doesn't create new tables.
>
> Also I changed usage of enable_sort to enable_groupagg as you
> suggested. I will have to change it to enable_sort during
> backpatching.

Any objections if I push (and backpatch) this?

------
Regards,
Alexander Korotkov
Supabase