On Wed, Feb 23, 2011 at 3:16 PM, Andrew Dunstan <and...@dunslane.net> wrote: > On 02/23/2011 10:09 AM, Peter Geoghegan wrote: >> >> On 23 February 2011 04:36, Greg Stark<gsst...@mit.edu> wrote: >>> >>> This is only true for server encodings. In a client library I think >>> you lose on this and do have to deal with it. I'm not sure what client >>> encodings we do support that aren't ascii-supersets though, it's >>> possible none of them generate quote characters this way. >> >> I'm pretty sure all of the client encodings Tatsuo mentions are ASCII >> supersets. The absence of by far the most popular non-ASCII superset >> encoding, UTF-16, as a client encoding indicated that to me. It isn't >> byte oriented, and Postgres is. > > > They are not. It's precisely because they are not that they are not allowed > as server encodings. >
Well just as an example, BIG5 is a 16-bit encoding where the first byte always has the high bit set. The second byte can't be a ' or " because those aren't in the allowable range for the second byte. So it might be safe anyways. However \ is in the allowable range so I'm not sure. In the case of BIG5 ascii characters are included inline so any byte with the high bit *not* set that isn't the second byte of a two-byte sequence is assumed to be ascii. So an ascii parser would work fine modulo the problem above with backslashes. But this is just a special case. Wikipedia implies it's also true for shift-JIS but there's no guarantee it would work for other client encodings. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
