On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Right. Or, if someone someday implements a feature to allow multiple
server encodings within the same database, then we can tell people to
use it if they want JSON to work in a spec-canonical way.
> BTW, could the \uNNNN problem be finessed by leaving such escapes in
> source form?
Joey seems to want to canonicalize the input, which argues against
that, and to detect invalid surrogate pairs, which likewise argues
against that. You could argue that's overkill, but it seems to have
at least some merit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company