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
-
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