Re: [HACKERS] psql -f inconsistency with "copy from stdin"
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] psql -f inconsistency with "copy from stdin" |
Дата | |
Msg-id | 9069.947659376@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql -f inconsistency with "copy from stdin" (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [HACKERS] psql -f inconsistency with "copy from stdin"
Re: [HACKERS] psql -f inconsistency with "copy from stdin" |
Список | 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 по дате отправления: