On Jul20, 2011, at 06:40 , Joey Adams wrote: > On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> Thanks for the input. I'm leaning in this direction too. However, it >>> will be a tad tricky to implement the conversions efficiently, ... >> >> I'm a bit confused, because I thought what I was talking about was not >> doing any conversions in the first place. > > We want to be able to handle \uXXXX escapes when the database encoding > is not UTF-8. We could leave them in place, but sooner or later > they'll need to be converted in order to unwrap or compare JSON > strings.
Hm, I agree that we need to handle \uXXXX escapes in JSON input. We won't ever produce them during output though, right? > The approach being discussed is converting escapes to the database > encoding. This means escapes of characters not available in the > database encoding (e.g. \u266B in ISO-8859-1) will be forbidden. > > The PostgreSQL parser (which also supports Unicode escapes) takes a > simpler approach: don't allow non-ASCII escapes unless the server > encoding is UTF-8. Maybe JSON should simply reject them too, then. At least for now. How does that XML type handle the situation? It seems that it'd have the same problem with unicode entity references "&#XXXX;". best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
