On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan <and...@dunslane.net> wrote: > On 01/19/2012 03:49 PM, Robert Haas wrote: >> In other words, let's decree that when the database encoding isn't >> UTF-8, *escaping* of non-ASCII characters doesn't work. But >> *unescaped* non-ASCII characters should still work just fine. > > The spec only allows unescaped Unicode chars (and for our purposes that > means UTF8). An unescaped non-ASCII character in, say, ISO-8859-1 will > result in something that's not legal JSON. See > <http://www.ietf.org/rfc/rfc4627.txt?number=4627> section 3.
I understand. I'm proposing that we not care. In other words, if the server encoding is UTF-8, it'll really be JSON. But if the server encoding is something else, it'll be almost-JSON. And specifically, the \uXXXX syntax won't work, and there might be some non-Unicode characters in there. If that's not the behavior you want, then use UTF-8. It seems pretty clear that we're going to have to make some trade-off to handle non-UTF8 encodings, and I think what I'm suggesting is a lot less painful than disabling high-bit characters altogether. If we do that, then what happens if a user runs EXPLAIN (FORMAT JSON) and his column label has a non-Unicode character in there? Should we say, oh, sorry, you can't explain that in JSON format? That is mighty unfriendly, and probably mighty complicated and expensive to figure out, too. We *do not support* mixing encodings in the same database, and if we make it the job of this patch to fix that problem, we're going to be in the same place for 9.2 that we have been for the last several releases: nowhere. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
