Peter Eisentraut writes:
> Example: Create a cluster with non-C CTYPE, create a LATIN1 database,
> create a table with a bytea column, and store something with non-ASCII
> characters in it. Then change the client encoding (to UNICODE, say) and
> read the data. I stored 'ätsch bätsch' and got 'Ã
Peter Eisentraut wrote:
In general, the only safe solution would be to escape *all* byte
values on output. Then the client can reconstruct the byte sequence based
on the character entities in the delivered string and does not have to
rely on the character codes staying the same during the conversi
The bytea type seems to be liable to character set conversions to the
effect that it falsifies the stored data.
Example: Create a cluster with non-C CTYPE, create a LATIN1 database,
create a table with a bytea column, and store something with non-ASCII
characters in it. Then change the client en
