From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fixing backslash dot for COPY FROM...CSV |
Date: | 2024-04-02 19:44:08 |
Message-ID: | 1739536.1712087048@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> Robert Haas wrote:
>> Those links unfortunately seem not to be entirely specific to this
>> issue. Other, related things seem to be discussed there, and it's not
>> obvious that everyone agrees on what to do, or really that anyone
>> agrees on what to do.
> The proposed patch addresses these cases by making the sequence
> \. non-special in CSV (in fact backslash itself is a normal character in
> CSV).
> It does not address the cases when the data is embedded after
> the COPY command or typed interactively in psql, since these cases
> require an explicit end-of-data marker, and CSV does not have
> the concept of an end-of-data marker.
I've looked over this patch and I generally agree that this is a
reasonable solution. While it's barely possible that somebody
out there is depending on the current behavior of \. in CSV mode,
it seems considerably more likely that people who run into it
would consider it a bug. In any case, the patch isn't proposed
for back-patch, and as cross-version incompatibilities go this
seems like a pretty small one.
I concur with Robert's doubts about some of the doc changes though.
In particular, since we're not changing the behavior for non-CSV
mode, we shouldn't remove any statements that apply to non-CSV mode.
I'm also wondering why the patch adds a test for
"PQprotocolVersion(conn) >= 3" in handleCopyIn. As already
noted upthread, we ripped out all support for protocol 2.0
some time ago, so that sure looks like dead code.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Regina Obe | 2024-04-02 19:58:36 | RE: Crash on UNION with PG 17 |
Previous Message | Jeff Davis | 2024-04-02 19:40:36 | Re: New Table Access Methods for Multi and Single Inserts |