From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org, vik(at)postgresfriends(dot)org |
Subject: | Re: Row pattern recognition |
Date: | 2023-07-21 23:16:18 |
Message-ID: | e16dca82-5e22-c4fe-adc5-fb1f275e6daa@timescale.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/20/23 23:16, Tatsuo Ishii wrote:
> I don't know at this point. I think context-free is not enough to be
> repsented in Bison. The grammer also needs to be LALR(1). Moreover,
> adding the grammer to existing parser may generate shift/reduce
> errors.
Ah. It's been too long since my compilers classes; I will pipe down.
> One small concern is how to convert pattern variables to regex
> expression which our regex enginer understands. Suppose,
>
> PATTERN UP+
>
> Currently I convert "UP+" to "U+" so that it can be fed to the regexp
> engine. In order to do that, we need to know which part of the pattern
> (UP+) is the pattern variable ("UP"). For "UP+" it's quite easy. But
> for more complex regular expressions it would be not, unless PATTERN
> grammer can be analyzed by our parser to know which part is the
> pattern variable.
Is the eventual plan to generate multiple alternatives, and run the
regex against them one at a time?
>> I'm not familiar enough with this code yet to offer very concrete
>> suggestions, sorry... But at some point in the future, we need to be
>> able to skip forward and backward from arbitrary points, like
>>
>> DEFINE B AS B.price > PREV(FIRST(A.price), 3)
>>
>> so there won't be just one pair of "previous and next" tuples.
>
> Yes, I know.
I apologize. I got overexplain-y.
>> 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? 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?
Thanks!
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2023-07-21 23:38:01 | Re: Row pattern recognition |
Previous Message | Jacob Champion | 2023-07-21 23:14:12 | Re: Row pattern recognition |