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:

Reply via email to