Re: Alternative to \copy in psql modelled after \g - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Alternative to \copy in psql modelled after \g
Date
Msg-id 5803.1548686438@sss.pgh.pa.us
Whole thread Raw
In response to Re: Alternative to \copy in psql modelled after \g  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Alternative to \copy in psql modelled after \g  ("Daniel Verite" <daniel@manitou-mail.org>)
Re: Alternative to \copy in psql modelled after \g  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
"Daniel Verite" <daniel@manitou-mail.org> writes:
> Now as far as I can see, there is nothing that \copy to file or program
> can do that COPY TO STDOUT cannot do.

I don't think there's a way to get the effect of "\copy to pstdout"
(which, IIRC without any caffeine, means write to psql's stdout regardless
of where queryFout is currently pointing).  Somebody was excited enough
about that to submit a patch for it, so maybe it's worth covering.
My first thought about syntax is to define "\g -" as meaning that.

> The next thing would be to
> figure out how to similarly improve COPY FROM in psql, after which
> \copy might be seen as obsolete.

I suggested upthread that we could just define "\g foo" as reading
from foo, not writing it, if the command turns out to be COPY FROM.
Maybe that's too weird/mistake-prone?  A variant that might or might
not be safer is "\g <foo", ie we insist on you putting a mark there
that shows you intended to read.

Also, not quite clear what we'd do about copy-from-program.
I think "\g |foo" is definitely confusing for that.  "\g foo|"
would be better if it doesn't have syntax issues.

            regards, tom lane


pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: Alternative to \copy in psql modelled after \g
Next
From: Dmitry Dolgov
Date:
Subject: Re: Pluggable Storage - Andres's take