Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rrk3P-002QR0-FN for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Apr 2024 19:44:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rrk3O-00BMn7-Hf for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Apr 2024 19:44:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rrk3O-00BMmz-88 for pgsql-hackers@lists.postgresql.org; Tue, 02 Apr 2024 19:44:18 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rrk3H-000EpC-Hs for pgsql-hackers@postgresql.org; Tue, 02 Apr 2024 19:44:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 432Ji8gW1739537; Tue, 2 Apr 2024 15:44:08 -0400 From: Tom Lane To: "Daniel Verite" cc: "Robert Haas" , pgsql-hackers@postgresql.org Subject: Re: Fixing backslash dot for COPY FROM...CSV In-reply-to: <90523252-5831-4541-b3f6-0b3e03d428d2@manitou-mail.org> References: <90523252-5831-4541-b3f6-0b3e03d428d2@manitou-mail.org> Comments: In-reply-to "Daniel Verite" message dated "Wed, 24 Jan 2024 17:01:15 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1739535.1712087048.1@sss.pgh.pa.us> Date: Tue, 02 Apr 2024 15:44:08 -0400 Message-ID: <1739536.1712087048@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Daniel Verite" 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