Re: backslash-dot quoting in COPY CSV

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: backslash-dot quoting in COPY CSV
Date: 2019-01-25 12:01:22
Message-ID: a89f47e1-f716-4ae3-b882-cab5032a5d66@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:

> but I am able to see the failure using STDIN:
>
> COPY test FROM STDIN CSV;
> Enter data to be copied followed by a newline.
> End with a backslash and a period on a line by itself, or an EOF
> signal.
> "foo
> \.
> ERROR: unterminated CSV quoted field
> CONTEXT: COPY test, line 1: ""foo
>
> This seems like a bug to me. Looking at the code, psql issues the
> prompts for STDIN, but when it sees \. alone on a line, it has no idea
> you are in a quoted CSV string, so it thinks the copy is done and sends
> the result to the server. I can't see an easy way to fix this. I guess
> we could document it.

Thanks for looking into this.

\copy from file with csv is also affected since it uses COPY FROM
STDIN behind the scene. The case of embedded data looks more worrying
because psql will execute the data following \. as if they were
SQL statements.

ISTM that only ON_ERROR_STOP=on prevents the risk of SQL injection
in that scenario, but it's off by default.

What about this idea: when psql is feeding COPY data from its command
stream and an error occurs, it should act as if ON_ERROR_STOP was "on"
even if it's not.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2019-01-25 12:56:27 Re: Almost bug in COPY FROM processing of GB18030 encoded input
Previous Message Peter Eisentraut 2019-01-25 12:00:55 Re: pg_upgrade: Pass -j down to vacuumdb