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
