Re: Reject unsupported COPY FROM targets before analyzing WHERE clause

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

In response to

Browse pgsql-hackers by date

  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