Re: JSON for PG 9.2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: JSON for PG 9.2
Date
Msg-id CA+Tgmob+duoYxp2Sp17+DR0O66ezkF+71o14cEZF6J8Y6-NENg@mail.gmail.com
Whole thread Raw
In response to Re: JSON for PG 9.2  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: JSON for PG 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Re: JSON for PG 9.2  (Joey Adams <joeyadams3.14159@gmail.com>)
List pgsql-hackers
On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> Make JSON datatypes only selectable if client encoding is UTF-8.
>
> Yuck. Do we have this sort of restriction for any other data type?

No, and I don't think it's necessary to do it here, either.  Nor would
it be a good idea, because then the return value of EXPLAIN (FORMAT
JSON) couldn't unconditionally be json.  But I think the important
point is that this is an obscure corner case.  Let me say that one
more time: obscure corner case!

The only reason JSON needs to care about this at all is that it allows
\u1234 to mean Unicode code point 0x1234.  But for that detail, JSON
would be encoding-agnostic.  So I think it's sufficient for us to
simply decide that that particular feature may not work (or even, will
not work) for non-ASCII characters if you use a non-UTF8 encoding.
There's still plenty of useful things that can be done with JSON even
if that particular feature is not available; and that way we don't
have to completely disable the data type just because someone wants to
use EUC-JP or something.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: review: CHECK FUNCTION statement
Next
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe