Re: Fixing backslash dot for COPY FROM...CSV
Artur Zakirov <zaartur@gmail.com>
From: Artur Zakirov <zaartur@gmail.com>
To: Daniel Verite <daniel@manitou-mail.org>
Cc: Sutou Kouhei <kou@clear-code.com>, tgl@sss.pgh.pa.us, bruce@momjian.us, robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2024-09-23T15:38:56Z
Lists: pgsql-hackers
On Wed, 31 Jul 2024 at 15:42, Daniel Verite <daniel@manitou-mail.org> wrote:
>
> Sutou Kouhei wrote:
>
> > BTW, here is a diff after pgindent:
>
> PFA a v5 with the cosmetic changes applied.
Thank you Daniel for working on it. I've tested the patch and it seems
it works as expected.
I have a couple of minor comments.
It seems it isn't necessary to handle "\." within
"CopyAttributeOutCSV()" (file "src/backend/commands/copyto.c")
anymore.
/*
* Because '\.' can be a data value, quote it if it appears alone on a
* line so it is not interpreted as the end-of-data marker.
*/
if (single_attr && strcmp(ptr, "\\.") == 0)
use_quote = true;
You might see the difference in the test "cooy2.sql". Without changes
the output is:
=# COPY testeoc TO stdout CSV;
a\.
\.b
c\.d
"\."
Another thing is that the comparison "copystream ==
pset.cur_cmd_source" happens twice within "handleCopyIn()". TBH it is
a bit confusing to me what is the real purpose of that check, but one
of the comparisons looks unnecessary.
--
Kind regards,
Artur
Supabase
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