Re: BUG #14178: output of jsonb_object and json_object doesn't match textually

On Wed, Jun 08, 2016 at 08:32:41PM +1000, AP wrote:
> > So after thinking more on the matter, I'd rather give up on such
> > patches and recommend doing ::jsonb::text to be able to do equality
> > comparisons. If you want to get output similar to what jsonb is doing,
> > a simple cast with ::jsonb looks rather the saner way to go. This
> > induces more parsing cost, but that's the cost to pay...
>
> I think two things are being somewhat conflated:
>
> 1. the look of our JSON structures - we should be consistent here
> 2. the ordering of our JSON structures internally - a related (for the above
> use case issue) but, ultimately, seperate issue.
>
> 1 is easy to solve. JSON is JSON is JSON whether it's in a JSON data-type or
> JSONB and so no matter which it should look the same.
(docs snipped)
> As you can see, the key ordering is already covered. If you care, stick to JSON.
> If you don't, fly JSONB airlines.
>
> I think it's still worth doing #1 above and I'm willing to do the patch
> myself (it didn't occur to me how simple it was and I've been kicking myself
> at losing the opportunity to contribute :( :) ) if need be and if it'll fly.

Well I got bored and did it anyway. I checked all the functions in the doc page
and modified accordingly. My patch is, obviously, a superset of Michael's. :)

Interesting tidbit wrt this bit in the docs for JSON:

"Because the json type stores an exact copy of the input text, it will
preserve semantically-insignificant white space between tokens, as well
as the order of keys within JSON objects."
- https://www.postgresql.org/docs/current/static/datatype-json.html

json_strip_nulls doesn't appear to adhere to that:

moo=# select json_strip_nulls('{ "a":"b", "c":["a",2,-5,null], "d":{"e":"f", "true": false, "false": true, "val": null}}');
json_strip_nulls
-----------------------------------------------------------------------
{"a":"b","c":["a",2,-5,null],"d":{"e":"f","true":false,"false":true}}
(1 row)

Not sure if this should be fixed in-code or a note be made in the docs
of the exceptions.

Anyhow, patch attached.

Andrew