Re: COPY TO regression with psql -c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: COPY TO regression with psql -c
Date: 2026-08-13 20:44:35
Message-ID: 3598003.1786653875@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

After thinking some more about how to handle cases where we stop with
PSCAN_BACKSLASH or PSCAN_INCOMPLETE, I feel that the safest answer is
to set num_copy_from_stdin = 0 in those cases. This is consistent
with the fact that we know we won't get a PGRES_COPY_IN message,
even if there was a valid COPY FROM STDIN in the string before the
syntax error. This might prevent us from skipping following data
in cases where it'd be best to do that, but here are two arguments
against trying to do so:

* The ambition of the security patch extended only to handling
syntactically-valid cases, which these aren't. Trying to do more
leads into a guessing game, eg should we skip data after "COPY
mytable FRPM STDIN"?

* Not trying to skip data ensures that the behavior of such cases
is the same as it was before the security patch, which seems like
the right direction to err in.

So v3 attached does it like that. I also simplified the test
script. The two-COPY-commands case seems like it covers everything
we want to test; the other cases just add cycles and complicate
the script.

regards, tom lane

Attachment Content-Type Size
v3-0001-psql-count-every-COPY-FROM-STDIN-when-scanning-a-.patch text/x-diff 4.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Zsolt Parragi 2026-08-13 21:37:25 Re: REPACK (CONCURRENTLY) doesn't handle invalid indexes
Previous Message Nathan Bossart 2026-08-13 20:38:27 Re: Should CUSTER (ANALYZE) work?