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"  (Brook Milligan <brook@biology.nmsu.edu>)
Re: [HACKERS] psql -f inconsistency with "copy from stdin"  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] bug in 6.5.3...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: INDEX_MAX_KEYS = 16 ... it works, too