Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
Date
Msg-id 4091.1311016751@sss.pgh.pa.us
Whole thread Raw
In response to Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reduced power consumption in autovacuum launcher process
Next
From: Tom Lane
Date:
Subject: Re: patch for 9.2: enhanced errors