Обсуждение: Re: [PATCHES] Current-stream read for psql's \copy
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> No it doesn't. EOF will do fine. The source program doesn't
>> necessarily have to know anything about COPY, as long as its output is
>> in a format COPY can cope with (eg, tab-delimited).
> The current behavior seems quite strange and counter-intuitive. We
> might break the code for 1-2 people, but we will make it more
> predicable for everyone using it.
I don't think it's acceptable to simply remove the functionality.
If you wanted to argue about swapping the meanings of STDIN and -
(as defined by the patch) then we could debate about which way is
more consistent and whether it's worth breaking backwards compatibility
to improve consistency. I could probably be talked into supporting
that; as you say, we've done that before. But taking out a useful
behavior that has been there a long time, simply because you've decided
it's unintuitive, is not okay.
regards, tom lane
On Tue, 10 Feb 2004, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> No it doesn't. EOF will do fine. The source program doesn't > >> necessarily have to know anything about COPY, as long as its output is > >> in a format COPY can cope with (eg, tab-delimited). > > > The current behavior seems quite strange and counter-intuitive. We > > might break the code for 1-2 people, but we will make it more > > predicable for everyone using it. > > I don't think it's acceptable to simply remove the functionality. > If you wanted to argue about swapping the meanings of STDIN and - > (as defined by the patch) then we could debate about which way is > more consistent and whether it's worth breaking backwards compatibility > to improve consistency. I could probably be talked into supporting > that; as you say, we've done that before. But taking out a useful > behavior that has been there a long time, simply because you've decided > it's unintuitive, is not okay. Why not make a -i switch (for input file) that does it the way Bruce wants and leave -f alone so people who depend on it behaving the way it does won't get a surprise in their next upgrade?
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> No it doesn't. EOF will do fine. The source program doesn't > >> necessarily have to know anything about COPY, as long as its output is > >> in a format COPY can cope with (eg, tab-delimited). > > > The current behavior seems quite strange and counter-intuitive. We > > might break the code for 1-2 people, but we will make it more > > predicable for everyone using it. > > I don't think it's acceptable to simply remove the functionality. > If you wanted to argue about swapping the meanings of STDIN and - > (as defined by the patch) then we could debate about which way is > more consistent and whether it's worth breaking backwards compatibility > to improve consistency. I could probably be talked into supporting > that; as you say, we've done that before. But taking out a useful > behavior that has been there a long time, simply because you've decided > it's unintuitive, is not okay. I am reviewing our addition of '-' in CVS for psql \copy. Reading the manual, I think our current code is pretty confusing/contorted:For \copy table from filename operations, psqladds the option of usinga hyphen instead of filename. This causes \copy to read rows from thesame source that issuedthe command, continuing until \. is read or thestream reaches EOF. This option is useful for populating tables in-linewithina SQL script file. In contrast, \copy from stdin always readsfrom psql's standard input....Note: Note the differencein interpretation of stdin and stdout between\copy and COPY. In \copy these always refer to psql's input and outputstreams.In COPY, stdin comes from wherever the COPY itself came from(for example, a script run with the -f option),while stdout refers tothe query output stream (see \o meta-command below). "stdin is stdin except when it isn't stdin." :-) I think the biggest problem is that stdin/stdout in COPY is different from \copy. I propose we make stdin/stdout consistent for COPY and \copy, where stdin always reads from command input, and stdout always writes to command output. This does break backward compatibility of \copy for stdin/stdout; this change would have to be mentioned in the release notes. COPY is unaffected. I propose we add 'pstdin', and 'pstdout' to read from psql's stdin and stdout. I think that will greatly simplify our documentation, and clarify the stdin/stdout usage in all cases. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think the biggest problem is that stdin/stdout in COPY is different
> from \copy. I propose we make stdin/stdout consistent for COPY and
> \copy, where stdin always reads from command input, and stdout always
> writes to command output. This does break backward compatibility of
> \copy for stdin/stdout; this change would have to be mentioned in the
> release notes. COPY is unaffected.
> I propose we add 'pstdin', and 'pstdout' to read from psql's stdin and
> stdout. I think that will greatly simplify our documentation, and
> clarify the stdin/stdout usage in all cases.
What is "command output" and how does that differ from stdout?
I see the need to distinguish command input from psql stdin, since psql
may be reading the command from a file, but I don't see where there's
a stdout difference.
"pstdin" seems a bit contrived; I'm just as happy with using "-" as
the existing patch did. I'm fine with swapping the meanings to bring
\copy into line with COPY, though.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I think the biggest problem is that stdin/stdout in COPY is different > > from \copy. I propose we make stdin/stdout consistent for COPY and > > \copy, where stdin always reads from command input, and stdout always > > writes to command output. This does break backward compatibility of > > \copy for stdin/stdout; this change would have to be mentioned in the > > release notes. COPY is unaffected. > > > I propose we add 'pstdin', and 'pstdout' to read from psql's stdin and > > stdout. I think that will greatly simplify our documentation, and > > clarify the stdin/stdout usage in all cases. > > What is "command output" and how does that differ from stdout? > > I see the need to distinguish command input from psql stdin, since psql > may be reading the command from a file, but I don't see where there's > a stdout difference. > > "pstdin" seems a bit contrived; I'm just as happy with using "-" as > the existing patch did. I'm fine with swapping the meanings to bring > \copy into line with COPY, though. pstdout can be illustrated by this:$ sql -f /tmp/x testDROP TABLECREATE TABLEINSERT 17225 11$ sql -f /tmp/x -o /tmp/y test1 where /tmp/x is:DROP TABLE test;CREATE TABLE test (x int);INSERT INTO test VALUES (1);\copy test to stdout In this case, stdout is going to psql's stdout, not to the command stdout. The reason I didn't like '-' is that it is used mostly in Unix as synonym for stdin, and in this case it isn't a synonym --- it actually has different behavior. Using '-' which is a synonym for stdin causes confusion. I thought pstdin/pstdout were very clear in helping folks remember how it is different from stdin/stdout. Certainly it is contrived. Do you like appstdin and appstdout better, or psqlstdin and psqlstdout? -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> What is "command output" and how does that differ from stdout?
> In this case, stdout is going to psql's stdout, not to the command
> stdout.
Hm, I didn't realize it worked like that. So "command output" means
"where SELECT output would go"? Is that what happens to COPY TO STDOUT?
(experiments ... I guess so.)
> I thought pstdin/pstdout were very clear in helping folks remember how
> it is different from stdin/stdout.
Fair enough. If we need two flavors of stdout too, then I agree that
names are better than "-".
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> What is "command output" and how does that differ from stdout? > > > In this case, stdout is going to psql's stdout, not to the command > > stdout. > > Hm, I didn't realize it worked like that. So "command output" means > "where SELECT output would go"? Is that what happens to COPY TO STDOUT? > (experiments ... I guess so.) > > > I thought pstdin/pstdout were very clear in helping folks remember how > > it is different from stdin/stdout. > > Fair enough. If we need two flavors of stdout too, then I agree that > names are better than "-". We could get away with using '-' for stdin and stdout because we know by the "to"/"from" which it is, but again, the use of a synonym is confusing. -- 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