Re: multi-row INSERT broken with a sublink in a target column subscript

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: multi-row INSERT broken with a sublink in a target column subscript
Date: 2026-10-28 06:19:40
Message-ID: 0BF05E0C-2AAE-4EB3-96D6-F17B85D1E731@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Oct 28, 2026, at 08:42, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>
> When looking at whether there exist other sites in the parser that are
> like bug #19786, Claude found $subject.
>
> CREATE TABLE ta (a int[]);
> INSERT INTO ta (a[(SELECT 1)]) VALUES (1), (2);
> ERROR: unexpected non-SELECT command in SubLink
>
> The problem is that transformInsertStmt() transforms the target
> columns' indirection once per VALUES row without copying it, while
> transformSubLink() modifies the raw SubLink in place.
>
> a[(1 IS NULL)::int + 1] fails too, like this:
>
> INSERT INTO ta (a[(1 IS NULL)::int + 1]) VALUES (1), (2);
> ERROR: unrecognized node type: 7
>
> Attached patch fixes this.
>
> --
> Thanks, Amit Langote
> <v1-0001-Fix-multi-row-INSERT-with-a-sublink-in-a-target-c.patch>

The fix looks correct to me. I just have one nit.

When strip_indirection is false, we're building the final target list, so it should be safe to use col->indirection directly, since it won't be transformed again. Instead of unconditionally calling copyObject(), maybe we can do: strip_indirection ? copyObject(col->indirection) : col->indirection

I tried this change locally, and the new test case still passes.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Michael Paquier 2026-10-28 05:57:42 Re: Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY