Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Date: 2013-06-28 08:18:29
Message-ID: CAEZATCXhcVgx+jeMPLgHTeCSYAp+as6xtRx90V0PZGWd7O989Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 June 2013 15:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> Tom Lane said:
>>> Agreed, separating out the function-call-with-trailing-declaration
>>> syntaxes so they aren't considered in FROM and index_elem seems like
>>> the best compromise.
>>>
>>> If we do that for window function OVER clauses as well, can we make
>>> OVER less reserved?
>
>> Yes.
>
>> At least, I tried it with both OVER and FILTER unreserved and there
>> were no grammar conflicts (and I didn't have to do anything fancy to
>> avoid them), and it passed regression with the exception of the
>> changed error message for window functions in the from-clause.
>
>> So is this the final decision on how to proceed? It seems good to me,
>> and I can work with David to get it done.
>
> Yeah, please submit a separate patch that just refactors the existing
> grammar as above; that'll simplify reviewing.
>

In that case, I'll re-review the latest FILTER patch over the weekend
on the understanding that the reserved/unreserved keyword issue will
be resolved in separate patch.

Regards,
Dean

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2013-06-28 09:29:33 Re: Documentation/help for materialized and recursive views
Previous Message Maciej Gajewski 2013-06-28 08:10:02 Re: Review: query result history in psql