Skip site navigation (1) Skip section navigation (2)

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

From: Joe Conway <mail(at)joeconway(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Anders Hammarquist <iko(at)strakt(dot)com>,pgsql-bugs(at)postgresql(dot)org, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Subject: Re: Bug #728: Interactions between bytea and character encoding
Date: 2002-08-04 07:45:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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:

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 ;-)



In response to


pgsql-bugs by date

Next:From: pgsql-bugsDate: 2002-08-04 10:49:49
Subject: Bug #730: cannot create functional index
Previous:From: Joe ConwayDate: 2002-08-04 06:29:44
Subject: Re: Bug #728: Interactions between bytea and character encoding

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group