On 7/24/23 02:22, Tatsuo Ishii wrote:
What we are talking about here is *defining* a window
frame.
Well, we are defining a "reduced" window frame within a (full) window
frame. A "reduced" window frame is calculated each time when a window
function is called.
Why? It should only be recalculated when the current row changes and
we need a new frame. The reduced window frame *is* the window frame
for all functions over that window.
We already recalculate a frame each time a row is processed even
without RPR. See ExecWindowAgg.
Yes, after each row. Not for each function.
Also RPR always requires a frame option ROWS BETWEEN CURRENT ROW,
which means the frame head is changed each time current row position
changes.
Off topic for now: I wonder why this restriction is in place and whether
we should respect or ignore it. That is a discussion for another time,
though.
I strongly disagree with this. Window function do not need to know
how the frame is defined, and indeed they should not.
We already break the rule by defining *support functions. See
windowfuncs.c.
The support functions don't know anything about the frame, they just
know when a window function is monotonically increasing and execution
can either stop or be "passed through".
WinGetFuncArgInFrame should answer yes or no and the window function
just works on that. Otherwise we will get extension (and possibly even
core) functions that don't handle the frame properly.
Maybe I can move row_is_in_reduced_frame into WinGetFuncArgInFrame
just for convenience.
I have two comments about this:
It isn't just for convenience, it is for correctness. The window
functions do not need to know which rows they are *not* operating on.
There is no such thing as a "full" or "reduced" frame. The standard
uses those terms to explain the difference between before and after RPR
is applied, but window functions do not get to choose which frame they
apply over. They only ever apply over the reduced window frame.
--
Vik Fearing
