| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | surya poondla <suryapoondla4(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Reject unsupported COPY FROM targets before analyzing WHERE clause |
| Date: | 2026-11-03 07:33:13 |
| Message-ID: | 8995A6DD-50E4-45A0-B408-8B9BB4E10E8A@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Nov 3, 2026, at 08:33, surya poondla <suryapoondla4(at)gmail(dot)com> wrote:
>
> Hi Chao,
>
> I tested v2 on current master (51ae21aa313). The code change looks fine to me.
Thank you very much for your review.
>
> One more argument for it, on master the file is opened, or the program is run, before the relkind check fires. For example:
>
> create sequence s;
> copy s from program 'touch /tmp/marker';
> ERROR: cannot copy to sequence "s"
>
> On master /tmp/marker gets created; with v2 it doesn't. And copy s from '/nonexistent/file' fails with "could not open file" on master, but "cannot copy to sequence" with v2. Might be worth a line in the commit message.
Updated the comment message in v3.
>
> The copy2.sql change needs to be dropped, though. Since Tom's 3045a25ba81, which went in after v2, psql skips the in-line data when COPY FROM STDIN fails early. With test1 and . removed, psql now eats everything up to the next ., i.e. the CREATE FUNCTION, CREATE TRIGGER and the next COPY, and copy2 fails. If you keep those two lines, the expected output doesn't change.
Reverted the change in copy2.sql.
PFA v3.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Report-unsupported-COPY-FROM-targets-before-readi.patch | application/octet-stream | 4.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhijie Hou | 2026-11-03 07:43:57 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Jeevan Chalke | 2026-11-03 07:26:00 | Re: PL/pgSQL: apply the too_many_rows extra check to EXECUTE ... INTO |