Re: [HACKERS] Bytea misconceptions

[Peter Eisentraut]

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 'ätsch bätsch', which is
 not a suitable result for bytea data.

Another point that occured to me is that if you send bytea input that does
not exclusively contain escape sequences to the server, then you really
don't know what the server will store.  Since character set conversion is
supposed to be transparent, the bytea type is broken from the ground up
and should be replaced (probably by the standard blob type).

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [HACKERS] Bytea misconceptions

[Joe Conway]

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 conversion.
Seems like this brings us back to using hex for bytea, ala BLOB in 
SQL99. What would be the implications of changing byteain and byteaout 
to use X'FF' instead of '\377\377\377'?

I guess backward compatibility is a big problem. Maybe make it 
configurable: all octal escaped or all hex. Is it better to create a 
completely new datatype?

Joe



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])