Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN
Date
Msg-id 99860.1684509174@sss.pgh.pa.us
Whole thread Raw
In response to Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I agree that, in at least the json_agg case, the json array that is
> produced should be an json object with keys matching the names of the
> fields of the composite.

Well, it *is*, if the input is a composite value.  A bare NULL isn't
a composite value.  Observe the difference:

regression=# select to_json(null::b);
 to_json 
---------
 
(1 row)

regression=# select to_json(null::b) is null;
 ?column? 
----------
 t
(1 row)

regression=# select to_json(row(null,null)::b);
        to_json         
------------------------
 {"name":null,"a":null}
(1 row)

As I said, we do not treat null::b and row(null,null)::b exactly
alike.  We could spend a long time arguing about the merits of that
and whether or not it exactly satisfies the SQL spec, but at the end
of the day, the odds of it changing in Postgres are epsilon.  I do
not agree that it's wrong, and even if I did I doubt we'd take the
compatibility hit of changing it.

            regards, tom lane



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN
Next
From: "David G. Johnston"
Date:
Subject: Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN