Re: COPY fails on 8.1 with invalid byte sequences in text - Mailing list pgsql-bugs

From Jeff Davis
Subject Re: COPY fails on 8.1 with invalid byte sequences in text
Date
Msg-id 1162332910.31124.187.camel@dogma.v10.wvs
Whole thread Raw
In response to Re: COPY fails on 8.1 with invalid byte sequences in text  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: COPY fails on 8.1 with invalid byte sequences in text  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Tue, 2006-10-31 at 16:13 -0500, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.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.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #2726: reindex database failed if number is in database name
Next
From: Tom Lane
Date:
Subject: Re: BUG #2727: pg_restore error on BLOB COMMENTS