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 по дате отправления: