From: Jacob Champion <jchampion@timescale.com>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: pgsql-hackers@postgresql.org
Cc: vik@postgresfriends.org
Subject: Re: Row pattern recognition
Date: Fri, 21 Jul 2023 16:16:18 -0700
Message-ID: <e16dca82-5e22-c4fe-adc5-fb1f275e6daa@timescale.com> (raw)
In-Reply-To: <20230721.151648.412762379013769790.t-ishii@sranhm.sra.co.jp>
References: <07214b3a-5893-f6ce-ef55-0e5d24c94925@timescale.com>
<20230720.141513.1986681389874528348.t-ishii@sranhm.sra.co.jp>
<022a392f-2a9e-3df1-a509-a5bd51160fa5@timescale.com>
<20230721.151648.412762379013769790.t-ishii@sranhm.sra.co.jp>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jchampion@timescale.com, ishii@sraoss.co.jp, vik@postgresfriends.org
Subject: Re: Row pattern recognition
In-Reply-To: <e16dca82-5e22-c4fe-adc5-fb1f275e6daa@timescale.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox