Re: additional json functionality
От | David E. Wheeler |
---|---|
Тема | Re: additional json functionality |
Дата | |
Msg-id | 0CDEE52F-3EC2-42B4-9897-455721343604@justatheory.com обсуждение исходный текст |
Ответ на | Re: additional json functionality (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: additional json functionality
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: