On 7/22/23 08:14, Tatsuo Ishii wrote:
>> On 7/22/23 03:11, Tatsuo Ishii wrote:
>>> Maybe. Suppose a window function executes row pattern matching using
>>> price > PREV(price). The window function already receives
>>> WindowStatePerFuncData. If we can pass the WindowStatePerFuncData to
>>> PREV, we could let PREV do the real work (getting previous tuple).
>>> I have not tried this yet, though.
>>
>> I don't understand this logic. Window functions work over a window
>> frame.
>
> Yes.
>
>> 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.
>> How can a window function execute row pattern matching?
>
> A window function is called for each row fed by an outer plan. It
> fetches current, previous and next row to execute pattern matching. If
> it matches, the window function moves to next row and repeat the
> process, until pattern match fails.
>
> Below is an example window function to execute pattern matching (I
> will include this in the v3 patch). row_is_in_reduced_frame() is a
> function to execute pattern matching. It returns the number of rows in
> the reduced frame if pattern match succeeds. If succeeds, the function
> returns the last row in the reduced frame instead of the last row in
> the full window frame.
I strongly disagree with this. Window function do not need to know how
the frame is defined, and indeed they should not. 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.
--
Vik Fearing