From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, jchampion(at)timescale(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Row pattern recognition |
Date: | 2023-07-22 02:54:43 |
Message-ID: | c096c6cc-c3f6-8bbc-3d09-f36e9a8013e6@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-07-22 04:47:57 | Re: logicalrep_message_type throws an error |
Previous Message | Dean Rasheed | 2023-07-22 02:10:04 | Re: MERGE ... RETURNING |