From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] psql -f inconsistency with "copy from stdin" |
Date: | 2000-01-12 06:42:56 |
Message-ID: | 9069.947659376@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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 doing
psql -f driving.script <data.file
but on the other hand, it bothers me a good deal that a script
containing
COPY 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-12 07:01:58 | Re: INDEX_MAX_KEYS = 16 ... it works, too |
Previous Message | Tom Lane | 2000-01-12 06:33:01 | Re: [HACKERS] bug in 6.5.3... |