From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Tender Wang <tndrwang@gmail.com>,
        Duncan Sands <duncan.sands@deepbluecap.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: Attribute of type record has wrong type error with MERGE ... WHEN
 NOT MATCHED BY SOURCE THEN DELETE
In-reply-to: <m2gyjjk6hazud7hezz25t7aw7rjv73fthkct4jqbvrnu3ezqz3@nx3m53r7scce>
References: <971078.1741629162@sss.pgh.pa.us>
 <1207317.1741633880@sss.pgh.pa.us>
 <CAEZATCUQjxowkRfG89YOWStPvJ3xpJW9wDNccnZOVJzSAHwJxA@mail.gmail.com>
 <1213530.1741637326@sss.pgh.pa.us> <1620306.1741713271@sss.pgh.pa.us>
 <CAEZATCVcQXJ3KQUZyN-2=jzk6U1rByJ74Xfq84zeCGXxPQjEsg@mail.gmail.com>
 <1638469.1741723564@sss.pgh.pa.us> <1834982.1741729881@sss.pgh.pa.us>
 <CAEZATCWSTZSdzSZ9dnzbTpSa97Uit=KFz4KSgPfYLSwb4+P01w@mail.gmail.com>
 <2160671.1741794569@sss.pgh.pa.us>
 <m2gyjjk6hazud7hezz25t7aw7rjv73fthkct4jqbvrnu3ezqz3@nx3m53r7scce>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 12 Mar 2025 18:45:52 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2560747.1741824533.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Mar 2025 20:08:53 -0400
Message-ID: <2560748.1741824533@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2560748.1741824533%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> This seems to have introduce some breakage for 13-15. E.g. on
> sifaka:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dsifaka&dt=3D20=
25-03-12%2016%3A58%3A51
> which has
>     'CPPFLAGS' =3D> '-DWRITE_READ_PARSE_PLAN_TREES -DSTRESS_SORT_INT_MIN=
 -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS'

Ugh.  I supposed that it was okay that 317aba70e etc. didn't touch
outfuncs/readfuncs, but I did not think of
-DWRITE_READ_PARSE_PLAN_TREES.

Perhaps a good hack to deal with that is to make setrefs.c clear
out relid for RTE_SUBQUERY RTEs in those branches.  Then, in the
same way that the rte->function hack doesn't escape the planner,
this one wouldn't either.

			regards, tom lane