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
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 |