>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
>> So I've tried to rough out a decision tree for the various options >> on how this might be implemented (discarding the "use precedence >> hacks" option). Opinions? Additions? Tom> I think it'd be worth at least drafting an implementation for the Tom> lexical-lookahead fix. I think it's likely that we'll need to Tom> extend base_yylex to do more lookahead in the future even if we Tom> don't do it for this, given the SQL committee's evident love for Tom> COBOL-ish syntax and lack of regard for what you can do in Tom> LALR(1). That's not _quite_ a fair criticism of the SQL committee; they're not ignoring the capabilities of parsers, they're just not making their syntax robust in the presence of the kinds of extensions and generalizations that we want to do. Without exception that I know of, every time we've run into a problem that needed ugly precedence rules or extra lookahead it's been caused by us not reserving something that is reserved in the spec, or by us allowing constructs that are not in the spec at all (postfix operators, especially), or by us deliberately generalizing what the spec allows (e.g. allowing full expressions where the spec only allows column references, or allowing extra parens around subselects) or where we've repurposed syntax from the spec in an incompatible way (as in ANY(array)). Anyway, for the time being I will mark this patch as "returned with feedback". >> If the clauses are legal on all window functions, what to do about >> existing window functions for which the clauses do not make sense? Tom> Option 1: do nothing, document that nothing happens if w.f. Tom> doesn't implement it. That was 1.1.1 on my list. Tom> Option 2: record whether the inquiry functions got called. At end Tom> of query, error out if they weren't and the options were used. Erroring at the _end_ of the query seems a bit of a potential surprise. Tom> It's also worth wondering if we couldn't just implement the flags Tom> in some generic fashion and not need to involve the window Tom> functions at all. That was what I meant by option 1.1.2 on my list. Tom> FROM LAST, for example, could and perhaps should be implemented by Tom> inverting the sort order. Actually that can't work for reasons brought up in the recent discussion of optimization of window function sorts: if you change the sort order you potentially disturb the ordering of peer rows, and the spec requires that an (nth_value(x,n) from last over w) and (otherfunc(x) over w) for order-equivalent windows "w" must see the peer rows in the same order. So FROM LAST really does have to keep the original sort order, and count backwards from the end of the window. Tom> Possibly IGNORE NULLS could be implemented inside the Tom> WinGetFuncArgXXX functions? These behaviors might or might not Tom> make much sense with other window functions, but that doesn't seem Tom> like it's our problem. That's about what I was thinking for option 1.1.2, yes. -- Andrew (irc:RhodiumToad)