Re: Fixing backslash dot for COPY FROM...CSV

From: Artur Zakirov <zaartur(at)gmail(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: Sutou Kouhei <kou(at)clear-code(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us, bruce(at)momjian(dot)us, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixing backslash dot for COPY FROM...CSV
Date: 2024-09-23 15:38:56
Message-ID: CAKNkYnxur+x6KoOy0gfTyoQ=uTYo=d6f1eZRsB0Wmc+qh8RrNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 31 Jul 2024 at 15:42, Daniel Verite <daniel(at)manitou-mail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-09-23 15:50:21 Re: Large expressions in indexes can't be stored (non-TOASTable)
Previous Message Magnus Holmgren 2024-09-23 15:38:43 restrict_nonsystem_relation_kind led to regression (kinda)