On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
