agora inbox for pgsql-bugs@postgresql.org  

help / color / mirror / Atom feed

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
Date: Wed, 12 Aug 2026 13:58:42 -0400
Message-ID: <2801602.1786557522@sss.pgh.pa.us> (raw)
In-Reply-To: <CAN4CZFPqa6c+u4uX5jJ8LANHTQ4dxM3m4_8G9WmX_A4-2wuv2A@mail.gmail.com>
References: <CAN4CZFPqa6c+u4uX5jJ8LANHTQ4dxM3m4_8G9WmX_A4-2wuv2A@mail.gmail.com>

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

view thread (7+ messages)  latest in thread

Message-ID: <2801602.1786557522@sss.pgh.pa.us>
Permalink:  ../2801602.1786557522@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2801602.1786557522@sss.pgh.pa.us

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, zsolt.parragi@percona.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: COPY TO regression with psql -c
  In-Reply-To: <2801602.1786557522@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox