Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, david@fetter.org,
Oliver Ford <ojford@gmail.com>, Krasiyan Andreev <krasiyan@gmail.com>
Date: 2018-09-23T22:22:30Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix coding style with "else".
- 20628b62e46e 19 (unreleased) landed
-
Fix multi WinGetFuncArgInFrame/Partition calls with IGNORE NULLS.
- 2d7b247cb414 19 (unreleased) landed
-
Fix Coverity issue reported in commit 2273fa32bce.
- dd766a441d69 19 (unreleased) landed
-
Use ereport rather than elog in WinCheckAndInitializeNullTreatment.
- 5f3808646f67 19 (unreleased) landed
-
Avoid uninitialized-variable warnings from older compilers.
- 71540dcdcb22 19 (unreleased) cited
-
Fix Coverity issues reported in commit 25a30bbd423.
- 2273fa32bce7 19 (unreleased) landed
-
Improve EXPLAIN's display of window functions.
- 8b1b342544b6 18.0 cited
-
Automatically generate node support functions
- 964d01ae90c3 16.0 cited
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> The FROM FIRST/LAST bit seems particularly badly thought through, Tom> because AFAICS it is flat out ambiguous with a normal FROM clause Tom> immediately following the window function call. The only way to Tom> make it not so would be to make FIRST and LAST be fully reserved, Tom> which is neither a good idea nor spec-compliant. In the actual spec syntax it's not ambiguous at all because NTH_VALUE is a reserved word (as are LEAD, LAG, FIRST_VALUE and LAST_VALUE), and OVER is a mandatory clause in its syntax, so a FROM appearing before the OVER must be part of a FROM FIRST/LAST and not introducing a FROM-clause. In our syntax, if we made NTH_VALUE etc. a col_name_keyword (and thus not legal as a function name outside its own special syntax) it would also become unambiguous. i.e. given this token sequence (with . marking the current posision): select nth_value(x) . from first ignore if we know up front that "nth_value" is a window function and not any other kind of function, we know that we have to shift the "from" rather than reducing the select-list because we haven't seen an "over" yet. (Neither "first" nor "ignore" are reserved, so "select foo(x) from first ignore;" is a valid and complete query, and without reserving the function name we'd need at least four tokens of lookahead to decide otherwise.) This is why I think the col_name_keyword option needs to be given serious consideration - it still doesn't reserve the names as strongly as the spec does, but enough to make the standard syntax work without needing any dubious hacks. -- Andrew (irc:RhodiumToad)