aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/pgstatfuncs.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-10-01 16:53:54 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-10-01 16:53:54 -0400
commitda8a4c1666476648659dc5fb6fc01ba5cd5d16a1 (patch)
treeb8d0ebae465e224a2e0f9c956a61a1ab0c5d8698 /src/backend/utils/adt/pgstatfuncs.c
parent983a588e0b864d5c016d5902217ba4b11fc82b4f (diff)
downloadpostgresql-da8a4c1666476648659dc5fb6fc01ba5cd5d16a1.tar.gz
postgresql-da8a4c1666476648659dc5fb6fc01ba5cd5d16a1.zip
Reject a copy EOF marker that has data ahead of it on the same line.
We have always documented that a copy EOF marker (\.) must appear by itself on a line, and that is how psql interprets the rule. However, the backend's actual COPY FROM logic only insists that there not be data between the \. and the following newline. Any data ahead of the \. is parsed as a final line of input. It's hard to interpret this as anything but an ancient mistake that we've faithfully carried forward. Continuing to allow it is not cost-free, since it could mask client-side bugs that unnecessarily backslash-escape periods (and thereby risk accidentally creating an EOF marker). So, let's remove that provision and throw error if the EOF marker isn't alone on its line, matching what the documentation has said right along. Adjust the relevant error messages to be clearer, too. Discussion: https://postgr.es/m/ed659f37-a9dd-42a7-82b9-0da562cc4006@manitou-mail.org
Diffstat (limited to 'src/backend/utils/adt/pgstatfuncs.c')
0 files changed, 0 insertions, 0 deletions