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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1qwtp8-00Ewkn-Ta
	for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Oct 2023 00:38:38 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1qwtp5-005tee-I0
	for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Oct 2023 00:38:35 +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 <bruce@momjian.us>)
	id 1qwtp5-005teW-8W
	for pgsql-hackers@lists.postgresql.org; Sun, 29 Oct 2023 00:38:35 +0000
Received: from momjian.us ([72.94.173.45])
	by makus.postgresql.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <bruce@momjian.us>)
	id 1qwtoy-002nuA-4l
	for pgsql-hackers@postgresql.org; Sun, 29 Oct 2023 00:38:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us;
	s=2023062407; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
	Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
	Content-Description; bh=1Rz3Xs3/0S14gHhWb0Y70tVnrRjQRZrHrgiXvIDbmLg=; b=pmZdY
	PE9rRu4PwjxBtpsEiwQ9FpZ4R1ezJndll7Y5S4v/fD0uG/L+DwEwNkzgn5kHNiz6BCUAUtJvoyWgB
	jUYGQdxaw3NFWV9hXAoopJKSczwXb2LeuclixGPKVp3gwWtyPCQi/5IOXdC3QtG97ZLtjpCu1u7vA
	XUsjUa4NMlvp1P0sXcA1NWZ43TYTzfDlNY1hh4P3JNcMbPMqwqoPiRRvIpYQHQTwuxE3pVHpQpcKg
	eGwNqV7hSp25RgWzwyPtZOTLp/GKn9FewQagfMYPiZLRVbg0NpnxFyXgP3p7cBQWZqLVq8XdKBBC1
	5+ENxOt8RMBYjNf0IiB1iwVCEYBRQ==;
Received: from bruce by momjian.us with local (Exim 4.96)
	(envelope-from <bruce@momjian.us>)
	id 1qwtow-009eTx-34;
	Sat, 28 Oct 2023 20:38:26 -0400
Date: Sat, 28 Oct 2023 20:38:26 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: rjuju123@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: COPY TO (FREEZE)?
Message-ID: <ZT2pgrRBeBFkSs-R@momjian.us>
References: <20220802.133046.1941977979333284049.horikyota.ntt@gmail.com>
 <20220802061746.4jjwudlkszpaqhbg@jrouhaud>
 <20220802.171735.1109220976200931645.horikyota.ntt@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="uLECUuUnQW7G+GD4"
Content-Disposition: inline
In-Reply-To: <20220802.171735.1109220976200931645.horikyota.ntt@gmail.com>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/ZT2pgrRBeBFkSs-R%40momjian.us>
Precedence: bulk


--uLECUuUnQW7G+GD4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Aug  2, 2022 at 05:17:35PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 2 Aug 2022 14:17:46 +0800, Julien Rouhaud <rjuju123@gmail.com> wrote in 
> > Hi,
> > 
> > On Tue, Aug 02, 2022 at 01:30:46PM +0900, Kyotaro Horiguchi wrote:
> > > I noticed that COPY TO accepts FREEZE option but it is pointless.
> > >
> > > Don't we reject that option as the first-attached does?
> > 
> > I agree that we should reject it, +1 for the patch.
> 
> Thanks for looking it!
> 
> > > By the way, most of the invalid option combinations for COPY are
> > > marked as ERRCODE_FEATURE_NOT_SUPPORTED.  I looks to me saying that
> > > "that feature is theoretically possible or actually realized
> > > elsewhere, but impossible now or here".
> > >
> > > If it is correct, aren't they better be ERRCODE_INVALID_PARAMETER_VALUE?  The
> > > code is being used for similar messages "unrecognized parameter <name>" and
> > > "parameter <name> specified more than once" (or some others?).  At least a
> > > quote string longer than a single character seems like to fit
> > > INVALID_PARAMETER_VALUE. (I believe we don't mean to support multicharacter
> > > (or even multibyte) escape/quote character anddelimiter).  That being said,
> > > I'm not sure if the change will be worth the trouble.
> > 
> > I also feel weird about it.  I raised the same point recently about COPY FROM +
> > HEADER MATCH (1), and at that time there wasn't a real consensus on the way to
> > go, just keep the things consistent.  I'm +0.5 on that patch for the same
> > reason as back then.  My only concern is that it can in theory break things if
> > you rely on the current sqlstate, but given the errors I don't think it's
> > really a problem.
> 
> Exactly. That is the exact reason for my to say "I'm not sure if..".  
> 
> > [1]: https://www.postgresql.org/message-id/flat/20220614091319.jk4he5migtpwyd7r%40jrouhaud#b18bf3705fb9f69d0112b6febf0fa1be
> 
> > Maybe that's just me but I understand "not supported" as "this makes
> > sense, but this is currently a limitation that might be lifted
> > later".
> 
> FWIW I understand it the same way.

I would like to apply the attached patch to master.  Looking at your
adjustments for ERRCODE_FEATURE_NOT_SUPPORTED to
ERRCODE_INVALID_PARAMETER_VALUE, I only changed the cases where it would
be illogical to implement the feature, not just that we have no
intention of implementing the feature.  I read "invalid" as "illogical".

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

--uLECUuUnQW7G+GD4
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="copy_csv.diff"

diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index d94e3cacfc..cc7d797159 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1119,6 +1119,10 @@ INSERT INTO tbl1 VALUES ($1, $2) \bind 'first value' 'second value' \g
         destination, because all data must pass through the client/server
         connection.  For large amounts of data the <acronym>SQL</acronym>
         command might be preferable.
+        Also, because of this pass-through method, <literal>\copy
+        ... from</literal> in <acronym>CSV</acronym> mode will erroneously
+        treat a <literal>\.</literal> data value alone on a line as an
+        end-of-input marker.
         </para>
         </tip>
 
diff --git a/src/bin/psql/copy.c b/src/bin/psql/copy.c
index b3cc3d9a29..8d6ce4cedd 100644
--- a/src/bin/psql/copy.c
+++ b/src/bin/psql/copy.c
@@ -627,6 +627,7 @@ handleCopyIn(PGconn *conn, FILE *copystream, bool isbinary, PGresult **res)
 						 * This code erroneously assumes '\.' on a line alone
 						 * inside a quoted CSV string terminates the \copy.
 						 * https://www.postgresql.org/message-id/E1TdNVQ-0001ju-GO@wrigleys.postgresql.org
+						 * https://www.postgresql.org/message-id/bfcd57e4-8f23-4c3e-a5db-2571d09208e2@beta.fastmail.com
 						 */
 						if ((linelen == 3 && memcmp(fgresult, "\\.\n", 3) == 0) ||
 							(linelen == 4 && memcmp(fgresult, "\\.\r\n", 4) == 0))

--uLECUuUnQW7G+GD4--