Re: Row pattern recognition

On 7/22/23 03:11, Tatsuo Ishii wrote:
>>>> Maybe
>>>> that can help clarify the design? It feels like it'll need to eventually
>>>> be a "real" function that operates on the window state, even if it
>>>> doesn't support all of the possible complexities in v1.
>>> Unfortunately an window function can not call other window functions.
>> Can that restriction be lifted for the EXPR_KIND_RPR_DEFINE case?

> I am not sure at this point. Current PostgreSQL executor creates
> WindowStatePerFuncData for each window function and aggregate
> appearing in OVER clause. This means PREV/NEXT and other row pattern
> navigation operators cannot have their own WindowStatePerFuncData if
> they do not appear in OVER clauses in a query even if PREV/NEXT
> etc. are defined as window function.
> 
>> Or
>> does it make sense to split the pattern navigation "functions" into
>> their own new concept, and maybe borrow some of the window function
>> infrastructure for it?

> 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.  What we are talking about here is *defining* a window frame. 
How can a window function execute row pattern matching?
-- 
Vik Fearing