Re: WITHIN GROUP patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: WITHIN GROUP patch
Date: 2013-12-07 22:16:06
Message-ID: 22969.1386454566@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> After examining this more closely, ISTM that the direct
> Tom> arguments are supposed to be processed as if they weren't inside
> Tom> an aggregate call at all. That being the case, isn't it flat
> Tom> out wrong for check_agg_arguments() to be examining the
> Tom> agg_ordset list? It should ignore those expressions whilst
> Tom> determining the aggregate's semantic level. As an example, an
> Tom> upper-level Var in those expressions isn't grounds for deciding
> Tom> that the aggregate isn't of the current query level.

> Hmm... yes, you're probably right; but we'd still have to check somewhere
> for improper nesting, no? since not even the direct args are allowed to
> contain nested aggregate calls.

Yeah, I had come to that same conclusion while making the changes;
actually, check_agg_arguments needs to look for aggs but not vars there.

In principle we could probably support aggs there if we really wanted to;
but it would result in evaluation-order dependencies among the aggs of a
single query level, which doesn't seem like something we want to take on
for a feature that's not required by spec.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2013-12-07 23:05:44 Re: Extension Templates S03E11
Previous Message Pavel Stehule 2013-12-07 21:57:47 Re: plpgsql_check_function - rebase for 9.3