From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: "variable not found in subplan target list"
In-reply-to: <3460255.1680008201@sss.pgh.pa.us>
References: <20230328112248.6as34mlx5sr4kltg@alvherre.pgsql> <3460255.1680008201@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 28 Mar 2023 08:56:41 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3463117.1680009420.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Mar 2023 09:17:00 -0400
Message-ID: <3463118.1680009420@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3463118.1680009420%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I reduced this down to

> MERGE INTO public.target_parted as target_0
>     USING public.itest1 as ref_0
>     ON target_0.b =3D ref_0.a
>     WHEN NOT MATCHED
>        THEN INSERT VALUES (42, 13);

> The critical moving part seems to just be that the MERGE target
> is a partitioned table ... but surely somebody tested that before?

Oh, it's not just any partitioned table:

regression=3D# \d+ target_parted
                                Partitioned table "public.target_parted"
 Column |  Type   | Collation | Nullable | Default | Storage | Compression=
 | Stats target | Description =

--------+---------+-----------+----------+---------+---------+------------=
-+--------------+-------------
 a      | integer |           |          |         | plain   |            =
 |              | =

 b      | integer |           |          |         | plain   |            =
 |              | =

Partition key: LIST (a)
Number of partitions: 0

The planner is reducing the scan of target_parted to
a dummy scan, as is reasonable, but it forgets to
provide ctid as an output from that scan; then the
parent join node is unhappy because it does have
a ctid output.  So it looks like the problem is some
shortcut we take while creating the dummy scan.

I suppose that without the planner bug, this'd fail at
runtime for lack of a partition to put (42,13) into.
Because of that, the case isn't really interesting
for production, which may explain the lack of reports.

			regards, tom lane