Re: additional json functionality

On 11/13/2013 04:58 PM, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> On 11/13/2013 11:37 AM, Merlin Moncure wrote:
>>> 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.
>>     An object is an unordered collection ofz ero or more name/value
>>     pairs
>>     ...
>>
>>     The names within an object SHOULD be unique.
>>
>> Forcing us to preserve order and key duplication would be a pretty effective
>> barrier to any performance improvements.
> SHOULD != MUST. Here is the definition of object per RFC 4627.
>
>    "An object structure is represented as a pair of curly brackets
>     surrounding zero or more name/value pairs (or members).  A name is a
>     string.  A single colon comes after each name, separating the name
>     from the value.  A single comma separates a value from a following
>     name.  The names within an object SHOULD be unique."
>
> And SHOULD means
>    "3. SHOULD. This word, or the adjective "RECOMMENDED", mean that
> there may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course."
>
> As far as I'm concerned, that settles things right there.  Beyond that
> (although they do say 'unordered' above), as a consequence of your
> argument the json strings {"a": 1, "b": 2} and {"b": 1, "a": 2} should
> be considered equivalent.  Another consequence is that creating
> particular legal constructions should be discouraged.  I disagree with
> this.
>
> This is simply not the case with many json consuming clients.  It's a
> nice idea but not how things work universally and that's exactly why
> the rules were hedged in the RFC.  I have a couple of cases right now
> where I'm producing key order sensitive json for some (admittedly not
> very well designed) json consuming clients that are out of my control.
>


I understand the difference between "should" and "must". But there is 
nothing that REQUIRES us to preserve key order or duplicate keys. If you 
really need textual preservation, you should probably store the data as 
text and convert it to json to do json-ish things to it. If not, we're 
going to face huge demands to implement another type which almost 
everyone but you will move to in rapid order because it performs so much 
better. The strong consensus I have seen in discussions at conferences 
and elsewhere is to go the way we're going, instead.

cheers

andrew