Re: additional json functionality

On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should
> require hstore to do things like build
>> 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.".
>
> This is pretty standard in the programming languages I know of which use
> JSON.
>
>> I think the caller should have no such
>> responsibility.  Keys should be able to repeated.
>
> Apparently your experience with using JSON in practice has been fairly
> different from mine; the projects I work on, the JSON is being
> constantly converted back and forth to hashes and dictionaries, which
> means that ordering is not preserved and keys have to be unique (or
> become unique within one conversion cycle).  I think, based on the
> language of the RFC and common practice, that it's completely valid for
> us to require unique keys within JSON-manipulation routines.

Common practice?  The internet is littered with complaints about
documents being spontaneously re-ordered and or de-duplicated in
various stacks.  Other stacks provide mechanisms for explicit key
order handling (see here: http://docs.python.org/2/library/json.html). Why do you think they did that?

I use pg/JSON all over the place.  In several cases I have to create
documents with ordered keys because the parser on the other side wants
them that way -- this is not a hypothetical argument.  The current
json serialization API handles that just fine and the hstore stuff
coming down the pike will not.  I guess that's a done deal based on
'performance'.  I'm clearly not the only one to have complained about
this though.

merln