Re: Fixing backslash dot for COPY FROM...CSV
Daniel Verite <daniel@manitou-mail.org>
From: "Daniel Verite" <daniel@manitou-mail.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Robert Haas" <robertmhaas@gmail.com>,pgsql-hackers@postgresql.org
Date: 2024-04-05T16:54:46Z
Lists: pgsql-hackers
Tom Lane wrote: > Not sure what to do here. One idea is to install just the psql-side > fix, which should break nothing now that version-2 protocol is dead, > and then wait a few years before introducing the server-side change. > That seems kind of sad though. Wouldn't backpatching solve this? Then only the users who don't apply the minor updates would have non-matching server and psql. Initially I though that obsoleting the v2 protocol was a recent move, but reading older messages from the list I've got the impression that it was more or less in the pipeline since way before version 10. Also one of the cases the patch fixes, the one when imported data are silently truncated at the point of \., is quite nasty IMO. I can imagine an app where user-supplied data would be appended row-by-row into a CSV file, and would be processed periodically by batch. Under some conditions, in particular if newlines in the first column are allowed, a malevolent user could submit a \. sequence to cause the batch to miss the rest of the data without any error being raised. [1] https://www.postgresql.org/message-id/11648.1403147417%40sss.pgh.pa.us Best regards, -- Daniel Vérité https://postgresql.verite.pro/ Twitter: @DanielVerite
Commits
-
Reject a copy EOF marker that has data ahead of it on the same line.
- da8a4c166647 18.0 landed
-
Do not treat \. as an EOF marker in CSV mode for COPY IN.
- 770233748981 18.0 landed
-
doc: \copy can get data values \. and end-of-input confused
- 42d3125adae1 17.0 cited