From: Tom Lane <tgl@sss.pgh.pa.us>
To: Zsolt Parragi <zsolt.parragi@percona.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: COPY TO regression with psql -c
In-reply-to: 
 <CAN4CZFPqa6c+u4uX5jJ8LANHTQ4dxM3m4_8G9WmX_A4-2wuv2A@mail.gmail.com>
References: 
 <CAN4CZFPqa6c+u4uX5jJ8LANHTQ4dxM3m4_8G9WmX_A4-2wuv2A@mail.gmail.com>
Comments: In-reply-to Zsolt Parragi <zsolt.parragi@percona.com>
	message dated "Tue, 11 Aug 2026 20:32:12 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2801601.1786557522.1@sss.pgh.pa.us>
Date: Wed, 12 Aug 2026 13:58:42 -0400
Message-ID: <2801602.1786557522@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2801602.1786557522%40sss.pgh.pa.us>
Precedence: bulk

Zsolt Parragi <zsolt.parragi@percona.com> writes:
> The recent COPY ... FROM STDIN improvement caused a regression in COPY
> TO ... FROM STDIN when used together with psql -c: it only considers
> the first statement, so the copy fails if multiple commands are
> specified. A very simple example is:

Yeah, this is clearly an oversight.

> I attached a proposed patch with a tap test case that showcases the issue.

I took a brief look at this.  The question the code immediately raises
is "what to do if we get PSCAN_BACKSLASH?".  For example, someone
might try
	psql postgres -c 'select 1; \echo hello\\ select 2;'
which is syntax that'd work just fine at a command prompt.  As things
stand today, we'll ship the whole string to the server, which will
throw a syntax error and do nothing.  (You could imagine improving the
-c option parser to split the string into pieces and make this work
like it does at a command prompt, but that's surely not something
we'd back-patch.)  Where the rubber meets the road for the current
problem is
	psql postgres -c 'select 1; \echo hello\\ copy tab from stdin;'
Should we act as though we expect PGRES_COPY_IN from this?  How about
	psql postgres -c 'copy tab from stdin; \echo hello'
?

Thinking about it, I think it's probably a non-problem in practice:
all of these forms will result in server errors with no PGRES_COPY_IN
issued, and since these don't attempt to consume data from the rest
of the -c string, there's not really a hazard of failing to skip over
data.  But I think the issue deserves explanation in a comment.

Also, I'd drop the resetPQExpBuffer(query_buf); line.  That's a false
analogy: since we're not sending the string-so-far to the server,
this situation is more like "\;" than like ";", and we'd not clear
query_buf for that.  It probably makes no difference right now, but
perhaps future lexer behavior would notice the difference.

On the test case: I don't love adding a new TAP script for this.
That implies spinning up a new server, making this very expensive
for the amount of actual testing it's doing.  Is there a reason not
to fold this into psql/t/001_basic.pl ?

			regards, tom lane