On Fri, Jun 21, 2013 at 11:33 AM, Jeff Davis <pg...@j-davis.com> wrote: >> Regardless of what syntax we settle on, we should also make sure that >> the conflict is intrinsic to the grammar and can't be factored out, as >> Tom suggested upthread. It's not obvious to me what the actual >> ambiguity is here. If you've seen "select lag(num,0)" and the >> lookahead token is "respect", what's the problem? It sort of looks >> like it could be a column label, but not even unreserved keywords can >> be column labels, so that's not it. Probably deserves a bit more >> investigation... > > I think the problem is when the function is used as a table function; > e.g.: > > SELECT * FROM generate_series(1,10) respect;
Ah ha. Well, there's probably not much help for that. Disallowing keywords as table aliases would be a cure worse than the disease, I think. I suppose the good news is that there probably aren't many people using RESPECT as a column name, but I have a feeling that we're almost certain to get complaints about reserving IGNORE. I think that will have to be quoted as a PL/pgsql variable name as well. :-( >> We could just add additional, optional Boolean argument to the >> existing functions. It's non-standard, but we avoid adding keywords. > > I thought about that, but it is awkward because the argument would have > to be constant (or, if not, it would be quite strange). True... but e.g. string_agg() has the same issue. -- Robert Haas 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
