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 encoding (to UNICODE, say) and read the data. I stored 'ätsch bätsch' and got 'ätsch bätsch', which is not a suitable result for bytea data. The bytea output function uses isprint() to determine which characters not to escape, which fails to give at least the documented results in most locales. 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 conversion. (Alternatively, we do not pass bytea values through the character set conversion, but that might be unfeasible for other reasons.) -- Peter Eisentraut [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
