From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Svante Richter <pgsql-bugs@richter.id>, pgsql-bugs@lists.postgresql.org
Subject: Re: COPY TO CSV produces data that is incompatible/unsafe for \COPY
 FROM CSV
In-reply-to: <20220814070053.GA92855@rfd.leadboat.com>
References: <bfcd57e4-8f23-4c3e-a5db-2571d09208e2@beta.fastmail.com>
 <20220814070053.GA92855@rfd.leadboat.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Sun, 14 Aug 2022 00:00:53 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <624692.1660486135.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Aug 2022 10:08:55 -0400
Message-ID: <624693.1660486135@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/624693.1660486135%40sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> The psql documentation says [\copy ... from stdin] looks for "\.".  It s=
ays
> nothing about doing that for [\copy ... from filename].  I wonder if psq=
l
> should change the filename case to send the whole file to the server, ig=
noring
> "\." inside.  (That is to say, change to match the psql documentation.)

This seems like a sensible solution.  The need to use an in-band EOF
marker when reading from the command source file is clear, and there's
no non-kluge way there.  But that doesn't mean we should extend it
to separate files.  (I'm surprised to realize we do, actually.)

			regards, tom lane