Re: "variable not found in subplan target list"
От | Tom Lane |
---|---|
Тема | Re: "variable not found in subplan target list" |
Дата | |
Msg-id | 3463118.1680009420@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "variable not found in subplan target list" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "variable not found in subplan target list"
|
Список | pgsql-hackers |
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 = 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=# \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
В списке pgsql-hackers по дате отправления: