Re: Fixing backslash dot for COPY FROM...CSV
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
Cc: "Artur Zakirov" <zaartur@gmail.com>, Sutou Kouhei <kou@clear-code.com>,
bruce@momjian.us, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2024-09-30T22:45:02Z
Lists: pgsql-hackers
Attachments
- v1-forbid-copy-EOF-marker-not-at-start-of-line.patch (text/x-diff) patch v1
"Daniel Verite" <daniel@manitou-mail.org> writes: > [ v6-0001-Support-backslash-dot-on-a-line-by-itself-as-vali.patch ] I did some more work on the docs and comments, and pushed that. Returning to my upthread thought that >>> I think we should fix it so that \. that's not alone on a line >>> throws an error, but I wouldn't go further than that. here's a quick follow-on patch to make that happen. It could probably do with a test case to demonstrate the error, but I didn't bother yet pending approval that we want to do this. (This passes check-world as it stands, indicating we have no existing test that expects this case to work.) Also, I used the same error message "end-of-copy marker corrupt" that we have for the case of junk following the marker, but I can't say that I think much of that phrasing. What do people think of "end-of-copy marker is not alone on its line", instead? regards, tom lane
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