Bug in psql COPY command
От | Joshua Jackson |
---|---|
Тема | Bug in psql COPY command |
Дата | |
Msg-id | 004401bfaa26$7049d7f0$2e0b030a@N55A6620 обсуждение исходный текст |
Ответы |
Re: Bug in psql COPY command
|
Список | pgsql-bugs |
============================================================================ POSTGRESQL BUG REPORT TEMPLATE ============================================================================ Your name : Joshua Jackson Your email address : jjackson@vortech.net System Configuration --------------------- Architecture (example: Intel Pentium) : Intel PIII Operating System (example: Linux 2.0.26 ELF) : Red Hat 6.1 / Linux 2.2.14 PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL 7.0RC1 Compiler used (example: gcc 2.8.0) : egcs-2.91.66 Please enter a FULL description of your problem: ------------------------------------------------ When using the "COPY" command to load a table in psql, if the row contains an ASCII NULL (0x0) or the "\" character, it will ignore whatever the field terminator for the column that this character is contained in. The result of which is all of the columns being shifted to the left (which results is a failed insert of a given row). Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: ---------------------------------------------------------------------- A text file containing the following (each field seperated by tabs) test1 test2 test3\ test4 1234 test5 to be copied into a table such as: create table test( f1 varchar(10), f2 varchar(10), f3 varchar(10), f4 varchar(10), f5 integer, f6 varchar(10) ); will fail with the error: ERROR: copy: line 1, Bad integer input format 'test5' The same result will be achieved if test3 was followed by an ASCII 0x0 If you know how this problem might be fixed, list the solution below: --------------------------------------------------------------------- I assume that this has to due with C string termination and escape sequences not being properly parsed.
В списке pgsql-bugs по дате отправления: