Re: How to stop array_to_json from interpolating column names that weren't there

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.

In response to

Responses

Browse pgsql-general by date

  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