Re: JSON for PG 9.2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JSON for PG 9.2
Date: 2011-12-16 13:52:45
Message-ID: CA+Tgmob+duoYxp2Sp17+DR0O66ezkF+71o14cEZF6J8Y6-NENg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 15, 2011 at 4:47 PM, Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-12-16 13:54:37 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Albe Laurenz 2011-12-16 13:49:43 Re: review: CHECK FUNCTION statement