Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls - Mailing list pgsql-hackers

From Nicholas White
Subject Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Date
Msg-id CA+=vxNY0FcOZ=YESGjp4BYpGrjSL8oDChtCMqqrMD4DaVU5vpQ@mail.gmail.com
Whole thread Raw
In response to Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Thanks for the reviews. I've attached a revised patch that has the lexer refactoring Alvaro mentions (arbitarily using a goto rather than a bool flag) and uses Jeff's idea of just storing the index of the last non-null value (if there is one) in the window function's context (and not the Datum itself).

However, Robert's right that SELECT ... ORDER BY respect NULLS LAST will now fail. An earlier iteration of the patch had RESPECT and IGNORE as reserved, but that would have broken tables with columns called "respect" (etc.), which the current version allows. Is this backwards incompatibility acceptable? If not, maybe I should try doing a two-token lookahead in the token-aggregating code between the lexer and the parser (i.e. make a RESPECT_NULLS token out of a sequence of RESPECT NULLS OVER tokens, remembering to replace the OVER token)? Or what about adding an %expect statement to the Bison grammar, confirming that the shift / reduce conflicts caused by using the RESPECT, IGNORE & NULL_P tokens the in out_clause rule are OK?

Thanks -

Nick
Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: SET work_mem = '1TB';
Next
From: "MauMau"
Date:
Subject: Re: Memory leak in PL/pgSQL function which CREATE/SELECT/DROP a temporary table