From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Guyren Howe <guyren(at)gmail(dot)com> |
Cc: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How to stop array_to_json from interpolating column names that weren't there |
Date: | 2017-07-20 04:28:59 |
Message-ID: | CAKFQuwan+Qc4OwTLWi7pLRDJNY4tcuWYS0eZtNr_+BWiK3ffiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jul 19, 2017 at 8:53 PM, Guyren Howe <guyren(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Lazurkin | 2017-07-20 10:26:45 | Re: Planner statistics usage for composite type |
Previous Message | Guyren Howe | 2017-07-20 03:53:06 | Re: How to stop array_to_json from interpolating column names that weren't there |