On Thu, Nov 14, 2013 at 11:34 AM, David E. Wheeler
<david@justatheory.com> wrote:
> On Nov 14, 2013, at 7:07 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>
>> This is exactly what needs to be done, full stop (how about: hstore).
>> It really comes down to this: changing the serialization behaviors
>> that have been in production for 2 releases (three if you count the
>> extension) is bad enough, but making impossible some legal json
>> constructions which are currently possible is an unacceptable
>> compatibility break. It's going to break applications I've currently
>> put into production with no clear workaround. This is quite frankly
>> not ok and and I'm calling foul. The RFC may claim that these
>> constructions are dubious but that's irrelevant. It's up to the
>> parser to decide that and when serializing you are not in control of
>> the parser.
>
> The current JSON type preserves key order and duplicates. But is it documented that this is a feature, or something
tobe guaranteed?
It doesn't, but the row_to_json function has a very clear mechanism of
action. And, 'not being documented' is not the standard for latitude
to make arbitrary changes to existing function behaviors.
> In my experience, no JSON parser guarantees key order or duplication.
I found one in about two seconds. http://docs.python.org/2/library/json.html
"object_pairs_hook, if specified will be called with the result of
every JSON object decoded with an ordered list of pairs. The return
value ofobject_pairs_hook will be used instead of the dict. This
feature can be used to implement custom decoders that rely on the
order that the key and value pairs are decoded (for example,
collections.OrderedDict() will remember the order of insertion). If
object_hook is also defined, the object_pairs_hooktakes priority."
That makes the rest of your argument moot. Plus, I quite clearly am
dealing with parsers that do.
merlin