Re: additional json functionality - Mailing list pgsql-hackers

On 11/14/2013 08:17 PM, Merlin Moncure wrote:
> 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.
the whole hash*() function family was changed based on "not documented"
premise, so we do have a precedent .
>
>> 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.
I am sure you could also devise an json encoding scheme
where white space is significant ;)

The question is, how much of it should json *type* support.

As discussed in other thread, most of your requirements
would be met by having json/row/row set-to-text serializer
functions which output json-formatted "text".

Then if you actually want to save this as easy to manipulate
json document, you can save this "text" to a field of type
"json", which does de-duplication and loses order.

So my suggestion is to upgrade existing json data type to
text - or maybe json_text with format check - when upgrading
to 9.4, to change current function which output "json"  to
output "text" and have new "json" type which stores proper
JavaScript Object - like structured data.

I would like to go a step further and have it automatically support
not only the json data types as data but all postgresql data types
by including type oid in the binary encoding, but this is probably not
something for "json" but rather for a new "pgdoc" data type in 9.5

Cheers

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ