Re: JSON for PG 9.2
От | Joey Adams |
---|---|
Тема | Re: JSON for PG 9.2 |
Дата | |
Msg-id | CAARyMpC_rsMgR2=39ExLkN36d8sozA_7TQHK1bJSA5PCDDBeuQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JSON for PG 9.2 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: JSON for PG 9.2
|
Список | pgsql-hackers |
On Fri, Dec 16, 2011 at 8:52 AM, Robert Haas <robertmhaas@gmail.com> wrote: > But I think the important point is that this is an obscure corner case. Let me say that one more time: obscure corner case! +1 > 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. So, if the server encoding is not UTF-8, should we ban Unicode escapes: "\u00FCber" or non-ASCII characters? "über" Also: * What if the server encoding is SQL_ASCII? * What if the server encoding is UTF-8, but the client encoding is something else (e.g. SQL_ASCII)? - Joey
В списке pgsql-hackers по дате отправления: