Hello. At Wed, 24 Jun 2026 15:34:07 +0800, Chao Li <[email protected]> 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
