On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer <craig@2ndquadrant.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
