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

  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