Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: sulfinu(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN
Date: 2023-05-19 15:12:54
Message-ID: 99860.1684509174@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2023-05-19 15:46:49 Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN
Previous Message David G. Johnston 2023-05-19 14:36:49 Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN