Thanks! The discussions have been useful, although I am currently just reviewing the code.
I think a good starting point will be to refactor/imrpove the WinGetFuncArgInPartition and WinGetFuncArgInFrame functions.
Tom Lane wrote this about them before comitting the patch:
I'm not terribly happy with the changes you made in WinGetFuncArgInPartition
and WinGetFuncArgInFrame to force the window function mark to not go
past frame start in some modes. Not only is that pretty ugly, but I
think it can mask bugs in window functions: it's an error for a window
function to fetch a row before what it has set its mark to be, but in
some cases that wouldn't be detected because of this change. I think
it would be better to revert those changes and find another method of
protecting fetches needed to determine the frame head. One idea is
to create a separate read pointer that tracks the frame head whenever
actual fetches of the frame head might be needed by update_frameheadpos.
I committed it without changing that, but I think this should be
revisited before trying to add the RANGE value PRECEDING/FOLLOWING
options, because those will substantially expand the number of caseswhere that hack affects the behavior.
I am honestly not 100% certain why these functions have issues, but this seems a good place to start investigating.
Ian Link
Thursday, June 20, 2013 7:37 PM
Good to know, and welcome.
I hope the links to the archived discussions on the matter were useful
to you.
Thursday, June 20, 2013 7:24 PM