From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: additional json functionality |
Date: | 2013-11-13 14:45:50 |
Message-ID: | CAHyXU0yW05G7aJ_Dwo9ZzxW6z_B8DEQYpTwVQC_6vTHx6dOUHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
>>
>> If there's agreement on taking these, I will prepare patches and submit
>> them by the 15th.
>
> With JSON enhancement, my only concern is that there's work ongoing to
> integrate the v2 development version of hstore with json, providing
> typed hstore and an efficient binary storage format for json.
>
> It might be worth seeing how that work is going and what functionality
> needs to be added to it, rather than enhancing the existing json support
> that may soon change dramatically.
I'm not so sure we should require hstore to do things like build
arbitrary json objects even though I agree that hstore will probably
displace json for must cases where you want to store nested data (as
opposed to (de-)serialize). Andrew's patches just fill out a couple
of missing cases that are handled in the existing API. Putting all
the patches together, ISTM there might be a function or two too many.
I'm not sure why the json_ prefix was abandoned for build_json_object
and build_json_array.
Also, json_object is pretty weird to me, I'm not sure I see the
advantage of a new serialization format, and I don't agree with the
statement "but it is the caller's reponsibility to ensure that keys
are not repeated.". I think the caller should have no such
responsibility. Keys should be able to repeated. Also, I'm not sure
how the {k,v,k,v,k,v}...convention serialized into a string is very
useful in general practice. I greatly prefer the aggregation and the
variadic methods in json_build.
Putting it all together, I'd consider:
*) dropping json_object (although maybe there is a case I'm not thinking about)
*) changing json_build function names to get the json prefix
*) adding a json object constructor that takes two parallel arrays as
arguments.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-11-13 14:54:53 | Re: Fast insertion indexes: why no developments |
Previous Message | Leonardo Francalanci | 2013-11-13 14:29:53 | Re: Fast insertion indexes: why no developments |