Joe Conway wrote: > Bruce Momjian wrote: > >> Does this mean we don't have to esacpe >0x7f when inputting bytea >> anymore? > > > I seem to remember that bytea data was run through the multibute code > for some reason, and I don't recall seeing that changed. ISTM that we > shouldn't force bytea thought multibyte functions at all. > > The UNKNOWNIN patch did address part of the problem, just not all of it. > Previously all 'unknown' data was initially cast as TEXT, and thus was > subject to multibyte character set interpretation. But there was another > execution path that was not dealt with. I'll search the archives for the > thread. >
Here's the remaining issue that I remembered; see: http://archives.postgresql.org/pgsql-hackers/2002-04/msg00256.php The gist of this is that when client and server encoding don't match, pg_do_encoding_conversion() gets called, regardless of data type. This is the *wrong thing* to do for BYTEA data, I think. Fixing this, combined with the UNKNOWNIN/OUT fix we did earlier, should eliminate the need to escape the high bit characters when inputting bytea. The only characters which *should* need to be escaped are the ones originally escaped by PQescapeBytea. IMHO of course ;-) Joe Joe ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
