Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
Subject: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Date: 2013-07-24 02:01:56
Message-ID: 20130724020156.GC166519@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 23, 2013 at 01:21:52AM +0000, Andrew Gierth wrote:
> For hypothetical set functions we add a special case, aggordnargs=-1,
> for which both the aggregate and the finalfn must be defined as
> (variadic "any") and parse analysis detects this case and unifies the
> types of the normal args with those of the ORDER BY args.

Other aggregates based on this syntax might not desire such type unification.
Having parse analysis do that distorts the character of an "any" argument. I
think the proper place for such processing is the first call to a transition
function. The transition functions could certainly call a new API exposed
under src/backend/parser to do the heavy lifting. But let's not make the
parser presume that an aggordnargs=-1 aggregate always wants its "any"
arguments handled in the manner of the standard hypothetical set functions.

The rest of the plan looks good so far.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2013-07-24 02:30:30 Re: maintenance_work_mem and CREATE INDEX time
Previous Message Noah Misch 2013-07-24 01:50:05 Re: Preventing tuple-table leakage in plpgsql