| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us |
| Subject: | Re: Reject unsupported COPY FROM targets before analyzing WHERE clause |
| Date: | 2026-06-25 07:11:29 |
| Message-ID: | 1E6DD776-FC25-4131-B657-B1221F8B82B8@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Jun 24, 2026, at 16:41, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> Hello.
>
> At Wed, 24 Jun 2026 15:34:07 +0800, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote in
>> It only fails with the root problem, “cannot copy to sequence”, after I type in the content I want to copy. I think that is too late. A better user experience would be to raise the root error before checking the WHERE clause and before waiting for any input.
>
> I agree that it would be better to fail before waiting for input.
> However, I am not sure that the unsupported-target error needs to take
> precedence over errors in the WHERE clause.
>
> For example, if we move the check in question from CopyFrom() to
> BeginCopyFrom(), the error would still be masked by WHERE-clause
> errors, but at least COPY FROM would no longer start reading input
> before reporting this error. That would also make the placement of
> this check more consistent with COPY TO. As far as I can tell, this
> check has been performed at different stages in COPY TO and COPY FROM
> for a long time, though I am not aware of any particular reason for
> the difference.
>
>> Similar masking can also happen with other checks, such as generated columns in COPY FROM WHERE conditions (v19 new) and COPY FROM on tables with row-level security.
>>
>> I tried a solution that splits the target relation pre-checks out of CopyFrom() and calls the pre-check earlier. With this patch, if a user copies to an unsupported target, such as a sequence, the command fails immediately without analyzing the WHERE clause or waiting for input.
>
> So I think the important part here is to avoid waiting for input when
> the command is doomed to fail. I am less convinced that we need to
> reorder the checks so that unsupported-target errors are always
> reported before WHERE-clause errors.
>
> Regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
Hi Kyotaro-san,
Thank you very much for the comments.
I still think the unsupported-target check should happen first, because that is the main problem. If a user spends time fixing a WHERE clause error, then the command to fails again with “cannot copy to xxx”, the user may feel frustrated.
But I am convinced by your point about making this consistent with COPY TO. So let’s use this patch to fix the “not waiting for input” problem first. I will try to work on the unsupported-target-check ordering for v20, considering COPY TO and COPY FROM together.
PFA v2. The patch is much simpler now. It only moves the unsupported-target check to BeginCopyFrom(), so the check happens before waiting for input.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Report-unsupported-COPY-FROM-targets-before-readi.patch | application/octet-stream | 5.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Sharma | 2026-06-25 07:31:04 | Re: Report bytes and transactions actually sent downtream |
| Previous Message | vignesh C | 2026-06-25 06:37:30 | Re: DOCS - clarify CREATE SUBSCRIPTION only synchronizes sequences when copy_data=true |