| 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 |
| 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? |