Re: BUG #15535: psql: \copy: parse error at... - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15535: psql: \copy: parse error at...
Date
Msg-id 7732.1544033557@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15535: psql: \copy: parse error at...  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-bugs
"Daniel Verite" <daniel@manitou-mail.org> writes:
> Tom Lane wrote:
>> Yeah, that is an issue all right.  It occurs to me that for the COPY TO
>> side, we don't really need any new command: we could just make \g work
>> for that case.  (Testing, it seems that plain "\g" works fine already,
>> but "\g foo" fails to redirect the COPY output, which seems to me to
>> be arguably a bug as well as lack of useful functionality.)
>> 
>> That approach does nothing for COPY FROM, though.  On the other hand,
>> it's not needed nearly as bad for COPY FROM, since you can't put a
>> giant sub-SELECT into that.

> Agreed. I will look into the problem of COPY OUT with \g filename
> if you don't beat me to it.

I wasn't volunteering to work on that, so have at it.

> Concerning \copyfrom, the most obvious use case is when the filename
> has to be a variable, which \copy doesn't allow for.
> But this one might be better solved by just improving \copy.

I wonder ... would it be outrageous for "\g foo" to be interpreted
as reading foo, not writing it, if what comes back from the server
is a CopyInResponse message rather than a query result or
CopyOutResponse?

No new commands that way, but maybe more potential for user confusion,
so I'm not sure if this is a good idea or not.

            regards, tom lane


pgsql-bugs by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: BUG #15535: psql: \copy: parse error at...
Next
From: PG Bug reporting form
Date:
Subject: BUG #15537: When trying to drop the column getting ERROR: vsnprintffailed: Invalid argument