Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org, david(at)fetter(dot)org, Oliver Ford <ojford(at)gmail(dot)com>, Krasiyan Andreev <krasiyan(at)gmail(dot)com>
Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Date: 2018-09-24 00:20:02
Message-ID: 11683.1537748402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> If you just think of recognizing FROM FIRST/LAST, you get nowhere
> Tom> because that's still legal in other contexts. But if you were to
> Tom> look for FROM followed by FIRST/LAST followed by
> Tom> IGNORE/RESPECT/OVER, I think that could only validly happen in
> Tom> this syntax.

> No; you need to go four tokens ahead in total, not three. Assuming
> nth_value is unreserved, then
> select nth_value(x) from first ignore;
> is a valid query that has nth_value(x) as an expression, "first" as a
> table name and "ignore" as its alias.

No, because once IGNORE is a keyword, even unreserved, it's not legal
as an AS-less alias. We'd be breaking queries like that no matter what.

(I know there are people around here who'd like to remove that
restriction, but it's not happening anytime soon IMO.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2018-09-24 00:26:44 Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Previous Message Michael Paquier 2018-09-24 00:12:38 Re: Proposal for Signal Detection Refactoring