Re: [GENERAL] How to stop array_to_json from interpolating column names that weren't there - Mailing list pgsql-general

From Tom Lane
Subject Re: [GENERAL] How to stop array_to_json from interpolating column names that weren't there
Date
Msg-id 6659.1500557630@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] How to stop array_to_json from interpolating columnnames that weren't there  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> 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 reason for that is that we interpret foo(*) as a call to a
zero-argument aggregate, in order to satisfy the spec's insistence
that "count(*)" is the way to invoke the argument-free form of count().
But there's no zero-argument function named json_agg().

I think David's answer was based on interpreting the command as

select json_agg(schemata.*) from schemata;

but that's something entirely different: it results in passing a
single composite-type argument to the function.  Yet again different
is use of * at top level of a SELECT list.

SQL is not the most consistent language in the world to begin with, and
some of these notations are things we inherited from Berkeley PostQUEL
and didn't want to give up, so it's a bit of a mess :-(

            regards, tom lane


pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: [GENERAL] _page_cost parameter with values < 1
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] _page_cost parameter with values < 1