On Fri, Sep 17, 2010 at 11:12 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Sat, Sep 18, 2010 at 11:46 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> <itagaki.takahiro@gmail.com> wrote:
>>> One of my proposal is we don't have to keep the original input text.
>>> We store JSON data in effective internal formats. If users want to get
>>> human-readable output, they can use stringify() with indentation option.
>>
>> There's a trade-off here: this will make some things faster, but other
>> things slower. Probably some discussion of the pros and cons is in
>> order.
>
> I didn't intended to introduce non-text internal formats. The original
> patch spent some codes to keep all of whitespaces as-is in the input.
> But I'd say we can simplify it.
>
> Except whitespaces, normalization of strings and numbers might be
> problem when we support JSON comparison operators -- comparison of
> Unicode escaped characters in strings or 0 vs. 0.0 in numbers.
Hmm, yeah. I'd be tempted to try to keep the user's original
whitespace as far as possible, but disregard it as far as equality
comparison goes. However, I'm not quite sure what the right thing to
do about 0 vs 0.0 is. Does the JSON spec say anything about that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
