| 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/
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Michael Paquier | 2026-10-28 05:57:42 | Re: Fix stale relcache fields for TOAST indexes during REINDEX CONCURRENTLY |