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