Re: additional json functionality - Mailing list pgsql-hackers

On 14/11/13 11:33, Andrew Dunstan wrote:
>
> 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
>
>
>
I can see that both points of view are valid, in different contexts.

Would be possible to have a boolean, such as 'strict' - so that unique & 
ordered was only imposed when strict was TRUE? Alternately, separate 
functions to allow the same choice?


Cheers,
Gavin