Re: nested hstore patch - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: nested hstore patch
Date
Msg-id 5284C66A.6070108@dunslane.net
Whole thread Raw
In response to Re: nested hstore patch  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: nested hstore patch  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
On 11/14/2013 03:21 AM, Hannu Krosing wrote:
> On 11/14/2013 01:32 AM, David E. Wheeler wrote:
>> On Nov 13, 2013, at 3:59 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
>>
>>> I remember strong voices in support of *not* normalising json, so that
>>> things like
>>>
>>> {"a":1,"a":true, "a":"b", "a":none}
>>>
>>> would go through the system unaltered, for claimed standard usage of
>>> json as
>>> "processing instructions". That is as source code which can possibly
>>> converted
>>> to JavaScript Object and not something that would come out of
>>> serialising of
>>> any existing JavaScript Object.
>> My recollection from PGCon was that there was consensus to normalize on
>> the way in --
> Great news! I remember advocating this approach in the mailing lists
> but having been out-voted based on "current real-world usage out there" :)
>>   or at least, if we switched to a binary representation as proposed by
>> Oleg & Teodor, it was not worth the hassle to try to keep it.
> Very much agree. For the source code approach I'd recommend
> text type with maybe a check that it is possible to convert it to json.
>


I don't think you and David are saying the same thing. AIUI he wants one 
JSON type and is prepared to discard text preservation (duplicate keys 
and key order). You want two json types, one of which would feature text 
preservation.

Correct me if I'm wrong.

cheers

andrew


>




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: init_sequence spill to hash table
Next
From: Andres Freund
Date:
Subject: Re: logical changeset generation v6.7