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: "Robert Haas" <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2024-04-05T16:02:37Z
Lists: pgsql-hackers
"Daniel Verite" <daniel@manitou-mail.org> writes:
> 	Tom Lane wrote:
>> I've looked over this patch and I generally agree that this is a
>> reasonable solution.

> Thanks for reviewing this!

While testing this, I tried running the tests with an updated server
and non-updated psql, and not only did the new test case fail, but
so did a bunch of existing ones.  That's because existing psql will
send the trailing "\." of inlined data to the server, and the updated
server will now think that's data if it's in CSV mode.

So this means that the patch introduces a rather serious cross-version
compatibility problem.  I doubt we can consider inlined CSV data to be
a niche case that few people use; but it will fail every time if your
psql is older than your server.

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.

An argument for not waiting is that psql may not be the only client
that needs this behavioral adjustment, and if so there's going to
be breakage anyway when we change the server; so we might as well
get it over with.

			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