Re: JSON for PG 9.2

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: JSON for PG 9.2
Дата
Msg-id CA+Tgmob+duoYxp2Sp17+DR0O66ezkF+71o14cEZF6J8Y6-NENg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: JSON for PG 9.2  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: JSON for PG 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Re: JSON for PG 9.2  (Joey Adams <joeyadams3.14159@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Albe Laurenz"
Дата:
Сообщение: Re: review: CHECK FUNCTION statement
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe