Dean Rasheed <dean.a.rash...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
