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

From Daniel Verite
Subject Re: BUG #15535: psql: \copy: parse error at...
Date
Msg-id 05a4c411-66fa-4bd0-bf80-98041a87c8de@manitou-mail.org
Whole thread Raw
In response to Re: BUG #15535: psql: \copy: parse error at...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15535: psql: \copy: parse error at...
List pgsql-bugs
    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.

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.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15535: psql: \copy: parse error at...
Next
From: Tom Lane
Date:
Subject: Re: BUG #15535: psql: \copy: parse error at...