Re: Row pattern recognition

Tatsuo Ishii <ishii@postgresql.org>

From: Tatsuo Ishii <ishii@postgresql.org>

To: assam258@gmail.com

Cc: david.g.johnston@gmail.com, vik@postgresfriends.org, jacob.champion@enterprisedb.com, er@xs4all.nl, peter@eisentraut.org, pgsql-hackers@postgresql.org

Date: 2026-01-07T03:21:54Z

Lists: pgsql-hackers

Hi Henson,

Thank you for the design proposal. I'm still learning it, and I have a
few questions for now.

> 3. Proper Lexical Order support
>    - Respects PATTERN alternative order for ONE ROW PER MATCH

RPR in WINDOW clause does not allow to specify "ONE ROW PER MATCH".
(nor ALL ROWS PER MATCH). So I am not sure what you mean here.

> 4. GREEDY/RELUCTANT quantifier support
>    - Longest vs shortest match semantics
> 
> 5. Incremental MEASURES computation
>    - Aggregate values computed during matching, no rescan needed

In my understanding MEASURES does not directly connect to Aggregate
computation with rescan. Can you elaborate why implementing MEASURES
allows to avoid recan for aggregate computation?

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Adjust cross-version upgrade tests for seg_out() fix
- 3e3d7875e956 19 (unreleased) cited
Rationalize error comments in partition split/merge tests
- ecb2508aaf9b 19 (unreleased) cited
Add fast path for foreign key constraint checks
- 2da86c1ef9b5 19 (unreleased) cited
Fix assorted pretty-trivial memory leaks in the backend.
- e78d1d6d47dc 19 (unreleased) cited
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 cited
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
Remove obsolete executor cleanup code
- d060e921ea5a 17.0 cited