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

Dean Rasheed <dean.a.rasheed@gmail.com> wrote:

> I'm still not happy that this patch is making FILTER a new reserved
> keyword, because I think it is a common enough English word (and an
> obscure enough SQL keyword) that people may well have used it for
> table names or aliases, and so their code will break.

Well, if it is a useful capability with a standard syntax, I think
we should go with the standard syntax even if it might break
application code that uses, as unquoted identifiers, words reserved
by the SQL standard.  Of course, non-reserved is better than
reserved if we can manage it.

> Playing around with the idea proposed there, it seems that it is
> possible to make FILTER (and also OVER) unreserved keywords, by
> splitting out the production of aggregate/window functions from normal
> functions in gram.y. Aggregate/window functions are not allowed in
> index_elem or func_table constructs, but they may appear in c_expr's.
> That resolves the shift/reduce conflicts that would otherwise occur
> from subsequent alias clauses, allowing FILTER and OVER to be
> unreserved.
>
> There is a drawback --- certain error messages become less specific,
> for example: "SELECT * FROM rank() OVER(ORDER BY random());" is now a
> syntax error, rather than the more useful error saying that window
> functions aren't allowed in the FROM clause. That doesn't seem like
> such a common case though.
>
> What do you think?

I think it is OK if that gets a syntax error.  If that's the "worst
case" I like this approach.

This also helps keep down the size of the generated parse tables,
doesn't it?

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company