On Wed, Nov 13, 2013 at 9:32 AM, Andrew Dunstan <and...@dunslane.net> wrote:
>> 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).
>
> I have no idea what this means.
What I'm saying there is I agree: what's going with hstore is not
relevant here. json features currently provide standalone
serialization and deserialization minus a couple of edge cases that
you are fixing up here. Hstore will emerge as a json manipulation
engine.
Aside: I thought we blew it (as you know) by not unifying the hstore
and json APIs in the 9.2 cycle and now with the emerging json stuff I
really think so...it's way to late to do anything about it now even if
there was consensus on that point.
>> Also, json_object is pretty weird to me, I'm not sure I see the
>> advantage of a new serialization format,
>
> What? there is no new serialization format. This is a way to generate a json
> object in the existing format from a one or two dimensional array of text.
> c.f. |existing function hstore(text[]) => hstore|
Right -- I thought it took text, not text[] -- withdrawn. I consider
a variant taking (text[], text[]) to be generally more practical than
the one argument version (either 1d or 2d variant). Dealing with 2d
arrays is a headache unless you really know what you're doing.
>> 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.
>
> They can be repeated, as they can in the current json text format. However,
> the function makes no attempt to deal with repeated keys. If a key is
> repeated in the inout it will be repeated in the output. In this respect it
> differs from the hstore function.
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot -- at least
not without extra scaffolding (at least, AIUI, I haven't fully
grappled with the coming hstore stuff yet). In other words, just
because key order and cardinality is unimportant in an associative
array, it does not in any way follow it is similarly unimportant for
object serialization.
> Note too, that one effect of moving to a non-text representation of json
> will be that duplicated keys will be resolved (last value will win). But
> that's a much wider issue that this function.
Right, exactly. And I think this a pretty serious problem with 'non
text json' unless there is a relatively robust and fast process to
recompose the json properly for serialization purposes (but that's
mostly off topic for your proposed patch).
>> 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.
>
> The extension was built before json_build. But it met a requirement that
> existed at the time. It probably wouldn't be a tragedy to leave it out, but
> there is probably a place for it just as there is for the hstore function.
>
>> 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.
>
> The third point seems to conflict with the first. I'd only consider that if
> we *do* add the one-array version of json_object.
ok, agreed. so now I'm just saying to unify function names over json
prefix and maybe add text[], text[] variant for the object builder, or
maybe just drop json_object completely.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
