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
