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 to
beguaranteed? Just because people have come to depend on something doesn’t mean we can’t change it. It’s one thing if
wesaid this was a feature you could depend on, but AFAIK we haven’t. And frankly, the dupes have caused problems for
someof my colleagues at work. To me, it’s a bug (or, at best, a mis-feature) that causes more issues than it prevents.
In my experience, no JSON parser guarantees key order or duplication. You can’t have dupes and there is no ordering in
aPerl hash, Objective-C NSDictionary, or JavaScript object. There is of course order and there can be dupes in a JSON
string,but not in the objects built from it. If you go in and out of a parser, dupes are eliminated and key order is
notpreserved. I expect the same from JSON storage.
With no guarantees of preserved ordering or duplication, and with no formal expectation of such by JSON parsers written
forvarious programming languages, I think there is little to be lost by removing those aspects of the JSON type. For
those(hopefully rare) situations where such expectations exist, the JSON should be stored as text, as Hannu suggests.
My $0.02.
Best,
David
