Re: 7.4 Wishlist

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: David Wheeler <david@wheeler.net>, Christopher Kings-Lynne <chriskl@familyhealth.com.au>, pgsql-hackers@postgresql.org
Date: 2002-12-02T18:09:46Z
Lists: pgsql-hackers, pgsql-general
Joe Conway wrote:
> David Wheeler wrote:
> > My understanding is that the nul character is legal in a byte sequence, 
> > but if it's not properly escaped, it'll be parsed as the end of the 
> > statement. Unfortunately, I think that it's a very tough problem to solve.
> 
> No question wrt '\0' bytes -- they would have to be escaped when casting from 
> bytea to text.
> 
> The harder issue is that there are apparently many other multiple byte 
> sequences that, while valid in an ASCII encoding, are not valid in one or more 
> multibyte encodings. See this thread:
> 
> http://archives.postgresql.org/pgsql-hackers/2002-04/msg00236.php
> 
> This is why currently all "non printable characters" are escaped (which I 
> think is all bytes > 127). Text on the other hand is already known to be valid 
> for a particular encoding, so it doesn't need escaping.
> 
> I'm not sure what happens when the backend encoding and client encoding don't 
> match -- I'd guess there is some probability of invalid byte sequences in that 
> case too.

I think there is some idea of changing the frontend/backend protocol to
prevent the need for escaping > \127 characters.  I believe it is
currently only required when the frontend/backend protocol have
different encodings.

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