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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Guyren Howe <guyren(at)gmail(dot)com>, 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 13:33:50
Message-ID: 6659.1500557630@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2017-07-20 13:40:19 Re: _page_cost parameter with values < 1
Previous Message Tom Lane 2017-07-20 13:19:10 Re: [GENERAL] huge RAM use in multi-command ALTER of table heirarchy