Message-ID: <e16dca82-5e22-c4fe-adc5-fb1f275e6daa@timescale.com>
Date: Fri, 21 Jul 2023 16:16:18 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: Row pattern recognition
Content-Language: en-US
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: pgsql-hackers@postgresql.org, vik@postgresfriends.org
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>
From: Jacob Champion <jchampion@timescale.com>
In-Reply-To: <20230721.151648.412762379013769790.t-ishii@sranhm.sra.co.jp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/e16dca82-5e22-c4fe-adc5-fb1f275e6daa%40timescale.com>
Precedence: bulk

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