From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: COPY fails on 8.1 with invalid byte sequences in text |
Date: | 2006-10-31 22:15:10 |
Message-ID: | 1162332910.31124.187.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 2006-10-31 at 16:13 -0500, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > I created a patch that appears to fix the problem, and does not appear
> > to break anything else.
>
> ... except maybe bytea ...
>
Ok. So then it seems that the only possible places to fix it are in
textin and all the other input functions for all the character types*,
or if we change COPY to use the send/recv functions rather than the
out/in functions.
I don't think we want to change the format for COPY, so is it reasonable
to change the input functions to reject invalid byte sequences?
COPY isn't just an issue for backups. Slony-I uses COPY to transfer
data, and if there are any invalid byte sequences than replication will
fail. The COPY doc page makes every implication that something COPY'd
out can be COPY'd back in in the same way.
Is this not a bug? Is there a discussion on -hackers about this that I
missed?
Regards,
Jeff Davis
* I don't immediately know what we'd do about "char". I think people
expect it to accept 256 values, but clearly that would violate a lot of
encodings. However, the current behavior creates the same problem with
COPY.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-31 23:18:37 | Re: BUG #2727: pg_restore error on BLOB COMMENTS |
Previous Message | Tom Lane | 2006-10-31 21:53:17 | Re: BUG #2726: reindex database failed if number is in database name |