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: Artur Zakirov <zaartur@gmail.com>,
Sutou Kouhei <kou@clear-code.com>,
bruce@momjian.us,
robertmhaas@gmail.com,
pgsql-hackers@postgresql.org
Date: 2024-10-01T19:34:20Z
Lists: pgsql-hackers
Tom Lane wrote: > > [ 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. Thanks! > 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. +1 for fixing. In particular, the behavior that silently drops data after a misplaced marker seems hard to argue for: postgres=# \copy foo(c1,c2) from stdin Enter data to be copied followed by a newline. End with a backslash and a period on a line by itself, or an EOF signal. >> a b >> c \. >> d e >> \. COPY 2 postgres=# table foo; c1 | c2 ----+---- a | b c | (2 rows) > 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? Yes, it's more precise and more helpful. 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