Re: [GENERAL] How to stop array_to_json from interpolating columnnames that weren't there

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [GENERAL] How to stop array_to_json from interpolating columnnames that weren't there
Дата
Msg-id CAKFQuwan+Qc4OwTLWi7pLRDJNY4tcuWYS0eZtNr_+BWiK3ffiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] How to stop array_to_json from interpolating columnnames that weren't there  (Guyren Howe <guyren@gmail.com>)
Ответы Re: [GENERAL] How to stop array_to_json from interpolating column names that weren't there
Список pgsql-general
On Wed, Jul 19, 2017 at 8:53 PM, Guyren Howe <guyren@gmail.com> wrote:
Thanks. Seeking greater understanding, why is json_agg(*) not equivalent?

​Are you referring to the fact that ​this provokes an error?

"select json_agg(*) from schemata;"

The json_agg(expression) function has an arity of 1 (i.e., one input argument only).  If you write:

select schemata from schemata;

you get one column in the output, while:

select * from schemata

results in an output relation having three columns - the "*" expands the composite type in the FROM clause into its component columns in the select-list

json_agg(*) fails since it is not expecting 3 columns (though oddly the error I see in 9.6 indicates its actually looking for a 0-arity function... "function json_agg() does not exist" - which implies that generally one cannot place a * in a function call, even if it would result in a single column.  This may even be documented but I haven't the desire to look right now...)

David J.


В списке pgsql-general по дате отправления:

Предыдущее
От: Guyren Howe
Дата:
Сообщение: Re: [GENERAL] How to stop array_to_json from interpolating columnnames that weren't there
Следующее
От: Dmitry Lazurkin
Дата:
Сообщение: Re: [GENERAL] Planner statistics usage for composite type