Re: [PATCHES] Current-stream read for psql's \copy

Bruce Momjian wrote:
> Bruce Momjian wrote:
> > 
> > What do people want to do with the current \copy behavior for stdin? 
> > Right now if you supply a file name with queries using psql -f, the copy
> > input is read from the terminal, not from the file.
> 
> Actually, I was wrong.  Right now \copy reads from psql's stdin, not
> always the terminal.  It doesn't read from the same descriptor it gets
> its SQL commands, unless they are the same as psql's stdin, like:
> 
>     psql test < commands.sql
> 
> You could make STDIN be the command stream, and add 'psqlstdin' for
> psql's stdin, but it seems like a very little used feature.  It doesn't
> seem worth documenting it, let alone adding code to allow it.
> 
> I assume \copy is designed primarily to allow reading from _local_ files
> rather than only files that exist on the database server, as COPY
> requires.

Now, I am really confused.  First I see the \copy from '-' is already in
CVS.   I missed that commit message, but it has been in for a few weeks.

Second, I think I now see the designer's goal of using stdin/stdout for
\copy.  \copy is for reading local files rather than only server files
via COPY, but for stdin/stdout, there isn't any 'local' file that makes
it different than COPY, so I am not sure even why someone would use
\copy when they could use COPY.

Also, I came upon this gem:
$ echo '\\copy test to stdout' | psql -o /tmp/z test444444444444444

Seems 'copy to stdout' also has this split idea of sending \copy output
to a different place from other output.

I guess my big question now is why someone would use \copy stdin/stdout
for reading input from the command stream when they can use COPY?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073