Re: [HACKERS] psql -f inconsistency with "copy from stdin" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] psql -f inconsistency with "copy from stdin"
Date
Msg-id 9069.947659376@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] psql -f inconsistency with "copy from stdin"  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [HACKERS] psql -f inconsistency with "copy from stdin"
Re: [HACKERS] psql -f inconsistency with "copy from stdin"
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> 7.0 behaves like 6.5.* in this regard because the code is pretty much the
> same. Thanks for pointing this out.

Of course, the question is which way is right...

I can see the potential usefulness of doingpsql -f driving.script <data.file
but on the other hand, it bothers me a good deal that a script
containingCOPY table FROM STDIN;... data here ...\.
(as generated by such unheard-of, seldom-used utilities as pg_dump)
would work when sourced by psql <pgdump.script and *fail* when sourced
by psql -f pgdump.script.  But that's what will happen if we change
it back.

I suspect the change in behavior from 6.4 to 6.5 may have been a
deliberate change to avoid this failure mode.  It'd be worth checking
the archives to see if you can find any discussion about it.

It seems to me that we ought to provide both behaviors, but make sure
that the one that supports data-in-the-script is the one invoked by
COPY FROM STDIN (since that's what pg_dump uses).  Perhaps psql's \copy
command can be set up to support the other alternative.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] bug in 6.5.3...
Next
From: Tom Lane
Date:
Subject: Re: INDEX_MAX_KEYS = 16 ... it works, too