| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-09 03:13:46 |
| Message-ID: | 87vbyyaflm.fsf@news-spur.riddles.org.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
Tom> We could alternatively decide that the agg has level 0, but that
Tom> doesn't seem terribly useful, and I think it's not per spec
Tom> either. SQL:2008 section 6.9 <set function specification> seems
Tom> pretty clear that only aggregated arguments should be considered
Tom> when determining the semantic level of an aggregate. OTOH, I
Tom> don't see any text there restricting what can be in the
Tom> non-aggregated arguments, so maybe the committee thinks this
Tom> case is sensible? Or they just missed it.
My bet is that they missed it, because there's another obvious
oversight there; it doesn't define column references in the FILTER
clause applied to an ordered set function as being aggregated column
references, yet it's clear that this must be the case (since they
filter the set of rows that the aggregated column references refer
to).
--
Andrew (irc:RhodiumToad)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2013-12-09 03:23:06 | Re: plpgsql_check_function - rebase for 9.3 |
| Previous Message | Michael Paquier | 2013-12-09 01:46:29 | Re: Possible work-around for 9.1 partial vacuum bug? |