Re: nested hstore patch

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: nested hstore patch
Date: 2013-11-14 16:50:02
Message-ID: 5284FF3A.7070107@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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Ü

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2013-11-14 16:54:54 Re: additional json functionality
Previous Message Hannu Krosing 2013-11-14 16:42:40 Re: additional json functionality