Re: Row pattern recognition

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: li(dot)evan(dot)chao(at)gmail(dot)com
Cc: vik(at)postgresfriends(dot)org, david(dot)g(dot)johnston(at)gmail(dot)com, jacob(dot)champion(at)enterprisedb(dot)com, er(at)xs4all(dot)nl, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2025-12-01 06:57:02
Message-ID: 20251201.155702.1354004661039447630.ishii@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Chao,

Sorry, I missed this email.

>> 9 - 0002 - parse_clause.c
>
> I am continuing to review 0003
>
> 10 - 0003
> ```
> + Assert(list_length(patternVariables) == list_length(defineClause));
> ```
>
> Is this assert true? From what I learned, pattern length doesn’t have to equal to define length. For example, I got an example from [1]:

You are right. If PATTERN clause uses the same pattern variable more
than once (which is perfectly valid), the assertion fails. I will
remove the assersion and fix the subsequent forboth loop.

> ```
> Example 4
> -- This example has three different patterns.
> -- Comment two of them, to get error-free query.
> SELECT company, price_date, price
> FROM stock_price
> MATCH_RECOGNIZE (
> partition by company
> order by price_date
> all rows per match
> pattern ( limit_50 up up* down down* )
> define
> limit_50 as price <= 50.00,
> up as price > prev(price),
> down as price < prev(price)
> )
> WHERE company = 'B'
> ORDER BY price_date;
> ```
>
> In this example, pattern has 5 elements and define has only 3 elements.

Yes.

> 11 - 0004 - plannodes.h
> ```
> + /* Row Pattern Recognition AFTER MACH SKIP clause */
> + RPSkipTo rpSkipTo; /* Row Pattern Skip To type */
> ```
>
> Typo: MACH -> MATCH

Will fix/

> I’d stop here, and continue 0005 tomorrow.

Thanks!

> [1] https://link.springer.com/article/10.1007/s13222-022-00404-3
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-12-01 07:01:52 Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp
Previous Message Bertrand Drouvot 2025-12-01 06:49:25 Re: Remove unused function parameters, part 2: replication