Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
| От | Tom Lane |
|---|---|
| Тема | Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON |
| Дата | |
| Msg-id | 4091.1311016751@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Initial Review: JSON contrib modul was: Re: Another
swing at JSON
Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams <joeyadams3.14159@gmail.com> wrote:
>> I'm having a really hard time figuring out how the JSON module should
>> handle non-Unicode character sets.
> But, again, why not just forget about transcoding and define it as
> "JSON, if you happen to be using utf-8 as the server encoding, and
> otherwise some variant of JSON that uses the server encoding as its
> native format?". It seems to me that that would be a heck of a lot
> simpler and more reliable, and I'm not sure it's any less useful in
> practice.
Right offhand, the only argument I can see against this is that we might
someday want to pass JSON datums directly to third-party loadable
libraries that are picky about UTF8-ness. But we could just document
and/or enforce that such libraries can only be used in UTF8-encoded
databases.
BTW, could the \uNNNN problem be finessed by leaving such escapes in
source form?
regards, tom lane
В списке pgsql-hackers по дате отправления: