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

сб, 12 сент. 2026 г., 18:57 Alexander Korotkov <aekorotkov(at)gmail(dot)com>:

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

Hi, Alexander!

I can't possibly have any :)
LGTM

>