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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN
Дата
Msg-id 99860.1684509174@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN