Re: Bug #728: Interactions between bytea and character encoding

I am hoping for a patch for this for 7.3. Added to open items:

Fix bytea to not encode input string

---------------------------------------------------------------------------

Joe Conway wrote:
> 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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073