Mark Feit wrote:
> This patch against 7.4.1's psql and the documentation adds the option
> of reading rows from the "current" input stream (standard input, -f
> xxx, \i xxx) during a "\copy ... from" operation in psql.  The details
> were proposed and discussed (somewhat) here:
> 
>   http://archives.postgresql.org/pgsql-hackers/2003-12/msg00687.php
>   http://archives.postgresql.org/pgsql-hackers/2004-01/msg00056.php
> 
> After some consideration, I decided to stick with the
> originally-proposed syntax because I couldn't come up with anything
> that made as much sense.
> 
> This patch also includes a change which makes the "enter data to be
> copied..." message appear for both \copy and COPY in an interactive
> setting.
> 
> If there's interest, I can build a patch against the current
> development version.

[ Moved to hackers list.]

Actually, I am confused by our current \copy behavior.  Given the
following file:

	CREATE TABLE test(x INT);
	\copy test FROM STDIN
	444
	\.
	SELECT * FROM test;

'psql test </tmp/x' works fine, but 'psql -f /tmp/x test' hangs waiting
for input from stdin.  Why would we want STDIN to read from the terminal
if all commands are being read from a file with -f?

Reading the second URL, I see:

> Peter Eisentraut declared that from that point on, stdin would be
> whatever stream the \copy command came from.  I'd like to propose a
> variant on the "FROM" clause which makes good on Peter's declaration
> without breaking anything already using FROM STDIN and expecting it
> to really read from stdin.  (I think this is for the better because
> there are lots of good uses for "psql -f foo.sql < foo.dat".)

I agree with Peter stdin should be where ever the commands are coming
from.  I don't see any value to keeping backward compatibility for such
strange behavior, and adding another flag to give the reasonable
behavior seems wrong too.

I propose we just fix this and document it in the release notes.  Heck,
COPY and \copy should behave the same in determining STDIN, and right
now they don't.

-- 
  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, Pennsylvania 19073

Tue, 10 Feb 2004 09:29:19 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 'psql test </tmp/x' works fine, but 'psql -f /tmp/x test' hangs waiting
> for input from stdin.  Why would we want STDIN to read from the terminal
> if all commands are being read from a file with -f?

Actually, that behavior is extremely useful.  Consider
	program-that-generates-data | psql -f somescript
The script can issue a COPY FROM STDIN to insert the data coming through
the pipe.

> I propose we just fix this and document it in the release notes.

I propose we not break existing applications.  If we change it the way
you suggest, there'll be no way to do the above.

			regards, tom lane

Tue, 10 Feb 2004 10:10:22 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > 'psql test </tmp/x' works fine, but 'psql -f /tmp/x test' hangs waiting
> > for input from stdin.  Why would we want STDIN to read from the terminal
> > if all commands are being read from a file with -f?
> 
> Actually, that behavior is extremely useful.  Consider
> 	program-that-generates-data | psql -f somescript
> The script can issue a COPY FROM STDIN to insert the data coming through
> the pipe.
> 
> > I propose we just fix this and document it in the release notes.
> 
> I propose we not break existing applications.  If we change it the way
> you suggest, there'll be no way to do the above.

But does anyone use such a capability?  The program has to generate \.
to terminate the input, so why not have it issue the \copy too?  Seems
cleaner.

-- 
  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, Pennsylvania 19073

Tue, 10 Feb 2004 10:16:14 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I propose we not break existing applications.  If we change it the way
>> you suggest, there'll be no way to do the above.

> But does anyone use such a capability?

What, you're going to remove a feature because you don't think it's
used?  We've been burnt by that approach before.

> The program has to generate \. to terminate the input

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).

			regards, tom lane

Tue, 10 Feb 2004 10:55:41 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> I propose we not break existing applications.  If we change it the way
> >> you suggest, there'll be no way to do the above.
> 
> > But does anyone use such a capability?
> 
> What, you're going to remove a feature because you don't think it's
> used?  We've been burnt by that approach before.

Yes.  We get burnt by it, but we also remove stuff we don't get burnt
by, so it is a value judgement.

> > The program has to generate \. to terminate the input
> 
> 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.

-- 
  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, Pennsylvania 19073

Tue, 10 Feb 2004 12:16:00 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
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

Tue, 10 Feb 2004 12:23:46 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy 
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 will do it by vote, not because _I_ decide it is unintuitive.  And I
don't have to talk _you_ into it, just a majority of developers.

-- 
  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, Pennsylvania 19073

Tue, 10 Feb 2004 12:28:47 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I will do it by vote, not because _I_ decide it is unintuitive.  And I
> don't have to talk _you_ into it, just a majority of developers.

[shrug...] Put it to a vote if you want; I feel sure you will lose.

There is another argument in favor of being able to read COPY data from
stdin (ie, not from the command script), which is that it is a security
feature that can help prevent SQL-injection attacks.  In the example of
	data-source-program | psql -f script
the upstream program *cannot* insert any SQL commands, it can only
source data that will go into exactly the table the script specifies.
The workaround you proposed of having the upstream issue COPY for itself
is insecure; it's quite analogous to allowing a user to enter unquoted
data into a SQL command string.

			regards, tom lane

Tue, 10 Feb 2004 12:36:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy 
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?


Tue, 10 Feb 2004 11:41:16 -0700 (MST)
"scott.marlowe" <scott.marlowe@ihs.com>
Re: [PATCHES] Current-stream read for psql's \copy 
Bruce Momjian writes:
 > 
 > I will do it by vote, not because _I_ decide it is unintuitive.  And I
 > don't have to talk _you_ into it, just a majority of developers.

Well, here's my vote on the subject: I purposefully avoided changing
the existing behavior because (a) it would break something I will
still find useful after the patch (b) I really think STDIN should mean
STDIN just as /some/file means /some/file.

What precipitated the patch in the first place was a need to be able
to do copies in-line to populate tables with small amounts of initial
data.  I like that initial data to be neat, readable and easy to
browse/modify without having to mentally filter through a lot of
INSERTs.  I have an automated system that takes a bunch of directories
containing various things like table creation and strings them
together into large SQL scripts to build, clear and destroy a
database.  Previously, I was having to deliver multiple files for
database builds; now I can just deliver one that does everything.

							- Mark
-- 
"DOS computers ... are by far the most popular, with about 70 million
 machines in use worldwide.  Macintosh fans ... note that cockroaches
 are far more numerous than humans, and that numbers alone do not
 denote a higher life form."   -- New York Times, November 26, 1991


Tue, 10 Feb 2004 13:44:22 -0500
Mark Feit <mfeit@notonthe.net>
Re: [PATCHES] Current-stream read for psql's \copy
Mark Feit <mfeit@notonthe.net> writes:
> What precipitated the patch in the first place was a need to be able
> to do copies in-line to populate tables with small amounts of initial
> data.

Right, that's clearly useful.  The debate at hand is about the
usefulness of the other behavior.

BTW, pg_dump scripts use COPY FROM STDIN (not \copy) to achieve this
same behavior of reading COPY data from the script file.  Your patch was
thus not strictly necessary, since there was already a way to do what it
did --- but I accepted it anyway, since it seems reasonable that \copy
should be able to do it too.

What Bruce is suggesting is that we remove the old \copy behavior and
make it *only* able to do what COPY FROM STDIN does.  That strikes me
as loss of important functionality ...

			regards, tom lane

Tue, 10 Feb 2004 13:57:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Current-stream read for psql's \copy 
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, psql adds the option of using
	a hyphen instead of filename. This causes \copy to read rows from the
	same source that issued the command, continuing until \. is read or the
	stream reaches EOF. This option is useful for populating tables in-line
	within a SQL script file. In contrast, \copy from stdin always reads
	from psql's standard input.
	
	...
	
	Note: Note the difference in interpretation of stdin and stdout between
	\copy and COPY. In \copy these always refer to psql's input and output
	streams. In COPY, stdin comes from wherever the COPY itself came from
	(for example, a script run with the -f option), while stdout refers to
	the 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, Pennsylvania 19073

Fri, 9 Apr 2004 13:35:58 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
stdin/stdout mismatch for COPY and \copy
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

Fri, 09 Apr 2004 13:59:33 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: stdin/stdout mismatch for COPY and \copy 
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 test
	DROP TABLE
	CREATE TABLE
	INSERT 17225 1
	1
	$ sql -f /tmp/x -o /tmp/y test
	1

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, Pennsylvania 19073

Fri, 9 Apr 2004 14:11:20 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: stdin/stdout mismatch for COPY and \copy
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

Fri, 09 Apr 2004 14:20:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: stdin/stdout mismatch for COPY and \copy 
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, Pennsylvania 19073

Fri, 9 Apr 2004 16:41:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: stdin/stdout mismatch for COPY and \copy
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 "-".

OK, the attached patch implements pstdin and pstdout, and change stdin
and stdout for \copy to be the same as COPY.  Using this file:
	
	drop table test;
	create table test (x int);
	insert into test values (1);
	\copy test from stdin

I get for stdin:

	$ psql -f /tmp/x -o /dev/null test

for pstdin:

	$ psql -f /tmp/x -o /dev/null test
	Enter data to be copied followed by a newline.
	End with a backslash and a period on a line by itself.
	test> 33
	test> \.

for stdout:

	$ psql -f /tmp/x -o /dev/null test

for pstdout:

	$ psql -f /tmp/x -o /dev/null test
	1

This breaks backward compatibility and has to be mentioned in the
release notes.

-- 
  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, Pennsylvania 19073

Index: doc/src/sgml/ref/psql-ref.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.109
diff -c -c -r1.109 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml	30 Mar 2004 15:54:33 -0000	1.109
--- doc/src/sgml/ref/psql-ref.sgml	10 Apr 2004 15:18:58 -0000
***************
*** 706,712 ****
          <term><literal>\copy <replaceable class="parameter">table</replaceable>
  	[ ( <replaceable class="parameter">column_list</replaceable> ) ]
          { <literal>from</literal> | <literal>to</literal> }
! 	{ <replaceable class="parameter">filename</replaceable> | stdin | stdout | - }
          [ <literal>with</literal> ] 
              [ <literal>oids</literal> ] 
              [ <literal>delimiter [as] </literal> '<replaceable class="parameter">character</replaceable>' ]
--- 706,712 ----
          <term><literal>\copy <replaceable class="parameter">table</replaceable>
  	[ ( <replaceable class="parameter">column_list</replaceable> ) ]
          { <literal>from</literal> | <literal>to</literal> }
! 	{ <replaceable class="parameter">filename</replaceable> | stdin | stdout | pstdin | pstdout }
          [ <literal>with</literal> ] 
              [ <literal>oids</literal> ] 
              [ <literal>delimiter [as] </literal> '<replaceable class="parameter">character</replaceable>' ]
***************
*** 736,753 ****
  	</para>
  
  	<para>
! 	For <literal>\copy <replaceable
  	class="parameter">table</replaceable> from <replaceable
! 	class="parameter">filename</replaceable></literal> operations,
! 	<application>psql</application> adds the option of using a
! 	hyphen instead of <replaceable
! 	class="parameter">filename</replaceable>.  This causes
! 	<literal>\copy</literal> to read rows from the same source that
! 	issued the command, continuing until <literal>\.</literal> is
! 	read or the stream reaches <acronym>EOF</>.  This option is
! 	useful for populating tables in-line within a SQL script file.
! 	In contrast, <literal>\copy from stdin</> always reads from
! 	<application>psql</application>'s standard input.
  	</para>
  
          <tip>
--- 736,752 ----
  	</para>
  
  	<para>
! 	<literal>\copy <replaceable
  	class="parameter">table</replaceable> from <replaceable
! 	class="parameter">stdin | stdout</replaceable></literal>
! 	reads/writes based on the command input and output respectively.
! 	All rows are read from the same source that issued the command,
! 	continuing until <literal>\.</literal> is read or the stream
! 	reaches <acronym>EOF</>. Output is sent to the same place as
! 	command output. To read/write from
! 	<application>psql</application>'s standard input or output, use
! 	<literal>pstdin</> or <literal>pstdout</>. This option is useful
! 	for populating tables in-line within a SQL script file.
  	</para>
  
          <tip>
***************
*** 759,778 ****
          </para>
          </tip>
  
-         <note>
-         <para>
-         Note the difference in interpretation of
-         <literal>stdin</literal> and <literal>stdout</literal> between
- 	<literal>\copy</literal> and <command>COPY</command>.
- 	In <literal>\copy</literal> these always
-         refer to <application>psql</application>'s input and output
-         streams. In <command>COPY</command>, <literal>stdin</literal> comes
- 	from wherever the <command>COPY</command> itself came from (for
-         example, a script run with the <option>-f</option> option), while
-         <literal>stdout</literal> refers to the query output stream (see
-         <command>\o</command> meta-command below).
-         </para>
-         </note>
          </listitem>
        </varlistentry>
  
--- 758,763 ----
Index: src/bin/psql/copy.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/bin/psql/copy.c,v
retrieving revision 1.42
diff -c -c -r1.42 copy.c
*** src/bin/psql/copy.c	29 Jan 2004 12:34:59 -0000	1.42
--- src/bin/psql/copy.c	10 Apr 2004 15:19:05 -0000
***************
*** 62,68 ****
  	char	   *table;
  	char	   *column_list;
  	char	   *file;			/* NULL = stdin/stdout */
! 	bool		in_dash;		/* true = use src stream not true stdin */
  	bool		from;
  	bool		binary;
  	bool		oids;
--- 62,68 ----
  	char	   *table;
  	char	   *column_list;
  	char	   *file;			/* NULL = stdin/stdout */
! 	bool		psql_inout;		/* true = use psql stdin/stdout */
  	bool		from;
  	bool		binary;
  	bool		oids;
***************
*** 220,240 ****
  	if (strcasecmp(token, "stdin") == 0 ||
  		strcasecmp(token, "stdout") == 0)
  	{
! 		result->in_dash = false;
  		result->file = NULL;
  	}
! 	else if (strcmp(token, "-") == 0)
  	{
! 		/* Can't do this on output */
! 		if (!result->from)
! 			goto error;
! 
! 		result->in_dash = true;
  		result->file = NULL;
  	}
  	else
  	{
! 		result->in_dash = false;
  		result->file = pg_strdup(token);
  		expand_tilde(&result->file);
  	}
--- 220,237 ----
  	if (strcasecmp(token, "stdin") == 0 ||
  		strcasecmp(token, "stdout") == 0)
  	{
! 		result->psql_inout = false;
  		result->file = NULL;
  	}
! 	else if (strcasecmp(token, "pstdin") == 0 ||
! 		strcasecmp(token, "pstdout") == 0)
  	{
! 		result->psql_inout = true;
  		result->file = NULL;
  	}
  	else
  	{
! 		result->psql_inout = false;
  		result->file = pg_strdup(token);
  		expand_tilde(&result->file);
  	}
***************
*** 394,400 ****
  	{
  		if (options->file)
  			copystream = fopen(options->file, "r");
! 		else if (options->in_dash)
   			copystream = pset.cur_cmd_source;
  		else
   			copystream = stdin;
--- 391,397 ----
  	{
  		if (options->file)
  			copystream = fopen(options->file, "r");
! 		else if (!options->psql_inout)
   			copystream = pset.cur_cmd_source;
  		else
   			copystream = stdin;
***************
*** 403,408 ****
--- 400,407 ----
  	{
  		if (options->file)
  			copystream = fopen(options->file, "w");
+ 		else if (!options->psql_inout)
+  			copystream = pset.queryFout;
  		else
  			copystream = stdout;
  	}
Sat, 10 Apr 2004 11:30:13 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: stdin/stdout mismatch for COPY and \copy