psql -f inconsistency with "copy from stdin"

Поиск
Список
Период
Сортировка
От Brook Milligan
Тема psql -f inconsistency with "copy from stdin"
Дата
Msg-id 200001112335.QAA00351@biology.nmsu.edu
обсуждение исходный текст
Ответы Re: [HACKERS] psql -f inconsistency with "copy from stdin"  (Peter Eisentraut <peter_e@gmx.net>)
Re: [HACKERS] psql -f inconsistency with "copy from stdin"  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Today I ran into an inconsistency between two versions of postgresql
in how psql handles copies from stdin.  At this point I am not sure
how the rewrite of psql does things, but thought I'd mention the
problem in case someone with it installed can check.

The issue is how the command
   psql -f test.sql db < test.dat

is treated, given the following files:
  -- test.sql  drop table test;  create table test (name text);  copy test from stdin;  select * from test;

and
  test.dat  a  b

Specifically v6.4.2 and v6.5.2 differ in the outcome, with v6.4.2
producing what I would expect and v6.5.2 producing anomalous output.
Note that performing the copy as
  psql -c "copy test from stdin" db < test.dat

works fine in either case.

v6.4.2 output:  The contents of test.dat are read into the table as
one might expect having redirected that file to stdin and copying from
stdin.

v6.5.2 output: The contents of test.dat are not read into the table at
all.  Instead, the remainder of the test.sql file (i.e., select * ...)
are read into the table.

How does the current version behave when performing these copies?  If
it still behaves like 6.5.2, I suspect there is some bug in handling
the copy command.

Cheers,
Brook



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Oliver Elphick"
Дата:
Сообщение: CREATE TABLE ... PRIMARY KEY kills backend
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] Potential vacuum bug?