>> 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?
Yes, that's my plan. >>> 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. No problem. Thank you for reminding me it. >>> 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. Best reagards, -- Tatsuo Ishii SRA OSS LLC English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp