On Mon, Apr 7, 2025 at 5:15 AM David Rowley wrote:
> Are these failures from patches applied to master prior to 3ba2cdaa?
Yea, my email was held in moderation for days. I guess cross-posting is
flagged. I thought I saw people regularly cc pgsql-hackers when replying to
pgsql-committers, but I g
Hi, David!
On Mon, Apr 7, 2025 at 12:15 PM David Rowley wrote:
>
> On Mon, 7 Apr 2025 at 19:39, Melanie Plageman
> wrote:
> > +++
> > C:/cirrus/build/testrun/pg_upgrade/002_pg_upgrade/data/results/subselect.out
> > 2025-04-04 14:47:20.358393500 +
> > @@ -2769,15 +2769,16 @@
> > EXPLAIN (C
On Mon, 7 Apr 2025 at 19:39, Melanie Plageman wrote:
> +++
> C:/cirrus/build/testrun/pg_upgrade/002_pg_upgrade/data/results/subselect.out
> 2025-04-04 14:47:20.358393500 +
> @@ -2769,15 +2769,16 @@
> EXPLAIN (COSTS OFF)
> SELECT c.oid,c.relname FROM pg_class c JOIN pg_am a USING (oid)
> WH
On Fri, Apr 4, 2025 at 6:47 PM Melanie Plageman
wrote:
>
> On Fri, Apr 4, 2025 at 9:17 AM Alexander Korotkov
> wrote:
> >
> > Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate
> >
> > This commit implements the automatic conversion of 'x IN (VALUES ...)' into
> > ScalarArrayOpExpr. T
On Fri, Apr 4, 2025 at 9:17 AM Alexander Korotkov
wrote:
>
> Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate
>
> This commit implements the automatic conversion of 'x IN (VALUES ...)' into
> ScalarArrayOpExpr. That simplifies the query tree, eliminating the appearance
> of an unnece
Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate
This commit implements the automatic conversion of 'x IN (VALUES ...)' into
ScalarArrayOpExpr. That simplifies the query tree, eliminating the appearance
of an unnecessary join.
Since VALUES describes a relational table, and the value
