From: | Michael Robinson <robinson(at)netrinsics(dot)com> |
---|---|
To: | pgsql-hackers(at)hub(dot)org |
Subject: | fatal copy in/out error (6.5.3) |
Date: | 2000-01-24 11:12:46 |
Message-ID: | 200001241112.TAA20988@netrinsics.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Do this:
testdb=> create table foo (word varchar(30));
CREATE
testdb=> insert into foo values ('\217\210');
INSERT 2337289 1
testdb=> copy "foo" to '/usr/local/pgsql/foo.out';
COPY
testdb=> \q
% od -c foo.out
0000000 217 210 \0 \n
0000004
One run produced:
0000000 217 210 \0 \b \n
In all cases, though, it emits a null. This, of course, causes "copy from" to
fail when it tries to parse a null-containing field in a multi-field record.
As for what the sequence "\217\210" represents, that's not really relevant
(it's not even a valid Chinese character, so far as I can tell). Someone
just entered this into our web interface and broke our database.
-Michael Robinson
P.S. As an aside, if "copy from" recognizes the \xxx octal convention, why
doesn't "copy to" use it to represent everything outside of \040..\176?
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-01-24 12:15:27 | Re: [HACKERS] Happy column dropping |
Previous Message | Zeugswetter Andreas SB | 2000-01-24 11:00:08 | Re: [HACKERS] column aliases |