Re: BUG #14178: output of jsonb_object and json_object doesn't match textually - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #14178: output of jsonb_object and json_object doesn't match textually
Date
Msg-id CAB7nPqReds5Hf+_Sd=sLT5D59AHnifg18QTWTe--Wh=fqzaqsg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14178: output of jsonb_object and json_object doesn't match textually  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: BUG #14178: output of jsonb_object and json_object doesn't match textually  (AP <ap@zip.com.au>)
List pgsql-bugs
On Tue, Jun 7, 2016 at 8:58 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> OK, that would make the entries generated a bit more compact.. Are
> there other opinions on the matter?

I have noticed as well that array elements separated by a comma use a
space after the comma with jsonb, and not with json. Still, doing
improvements in this area would be useful if a user is interested in
doing direct comparison of jsonb with json after casting them into
text to save some parsing cost. Still, an area where things are not
under controll with json is the key ordering within the same nest
level, which is on the contrary pre-defined in jsonb by the unicity of
the key names, and that's not the case of json. Take this example:

=# select row_to_json(r)::json from ( select relkind, oid::regclass as
name from pg_class where relname = 'pg_class') r;
            row_to_json
------------------------------------
 {"relkind":"r", "name":"pg_class"}
(1 row)
=# select row_to_json(r)::jsonb from (select relkind, oid::regclass as
name from pg_class where relname = 'pg_class') r;
             row_to_json
--------------------------------------
 {"name": "pg_class", "relkind": "r"}
(1 row)
This kills any hope of comparison.

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...
--
Michael

pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #14150: Attempted to delete invisible tuple
Next
From: Peter Tripp
Date:
Subject: Re: BUG #14150: Attempted to delete invisible tuple