Re: nested hstore patch - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: nested hstore patch
Date
Msg-id 5284FF3A.7070107@2ndQuadrant.com
Whole thread Raw
In response to Re: nested hstore patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: nested hstore patch  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 11/14/2013 01:47 PM, Andrew Dunstan wrote:
>
> 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.
I actually *want* the same thing that David wants, but I think that
Merlin has
valid concerns about backwards compatibility.

If we have let this behaviour in, it is not nice to break several uses
of it now.

If we could somehow turn "old json" into a text domain with json syntax
check
(which it really is up to 9.3) via pg_upgrade that would be great.

It would be the required for pg_dump to have some swicth to output
different typename in CREATE TABLE and similar.
>
> Correct me if I'm wrong.
>
> cheers
>
> andrew
>
>
>>
>


-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ




pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: additional json functionality
Next
From: Hannu Krosing
Date:
Subject: Re: additional json functionality