Re: [BUGS] \copy produces CSV output that cannot be read by \copy

On Sat, Aug 5, 2017 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> The format produced by COPY OUT looks fine to me, and can be reloaded
>> with a plain COPY (not \copy). And you may be interested in this bit
>> from src/bin/psql/copy.c:
>>                     /*
>>                      * This code erroneously assumes '\.' on a line alone
>>                      * inside a quoted CSV string terminates the \copy.
>>                      *
>> http://www.postgresql.org/message-id/E1TdNVQ-0001ju-GO@wrigleys.postgresql.org
>>                      */
>
> I wonder if it would improve matters to check for "\." only when
> copystream == pset.cur_cmd_source, that is, only when the copy data
> is inlined into the SQL stream.  That would create an inconsistency
> between inline and out-of-line data, but it might be a reasonable
> thing to do anyway.

A complete solution would be to look for the quote option provided by
the user and track if the string being passed to the backend is within
a quoted area or not, no? If that's a quoted area, the check for "\."
could be bypassed. Now, as parse_slash_copy() has its own way to parse
the command options given by the user, perhaps all this extra
engineering is not worth fixing an edge case.

In short, I agree that what you propose here has value to fix the case
proposed here, as even COPY FROM stdin (not only \copy) fails now.
-- 
Michael


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs