Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Nicholas White <n(dot)j(dot)white(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Date: 2013-06-21 18:11:47
Message-ID: CA+TgmoZH=D7psgkGpBHpOLYS590kTq4BTFXV8X0z-HipdMt-pw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 21, 2013 at 11:33 AM, Jeff Davis <pgsql(at)j-davis(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-06-21 18:13:04 Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Previous Message Thom Brown 2013-06-21 18:04:04 Unaccent performance