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

"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

  1. Reject a copy EOF marker that has data ahead of it on the same line.

  2. Do not treat \. as an EOF marker in CSV mode for COPY IN.

  3. doc: \copy can get data values \. and end-of-input confused