Re: Row pattern recognition
Henson Choi <assam258@gmail.com>
From: Henson Choi <assam258@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
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-12T11:12:39Z
Lists: pgsql-hackers
> > > After that, I'll implement PATH and CLASSIFIER functions, which depend on > > having > > the match context available. > > What is PATH function? It's not in R010 or R020 as far as I know. > A Match Path is essentially an array consisting of the CLASSIFIER() values of all rows within a matched sequence, arranged in chronological order. > > Longer-term, the goal is to get to MATCH_RECOGNIZE in the FROM clause for > > full SQL standard compliance. > > What about MEASURES clause? Without it, many things in the standard > cannot be implemented. > I admit that my current understanding of the full SQL standard is still evolving. However, looking at the current codebase, I believed that the syntax I've implemented so far could be addressed even before mastering every detail of the standard. That is why I have taken a 'code-first' approach for this stage. Of course, reaching 'FULL' compliance is undoubtedly the ultimate goal. Given the complexity, I believe the features should be released in several incremental phases. I trust that you will help define the strategic roadmap for these releases. As I continue to deepen my understanding of the standard, I will do my best to contribute to the technical roadmap as well. > > Let me know if you have any concerns or suggestions about the approach. > > Here are some comments on your patches. > > - It is based on my v36 patches. But the latest one is v37 patch. It > would be nice if you create patches based on the my latest patches. > I will rebase my work on your latest v37 patch and move forward with that for the next version. I’ll submit the updated patch soon. > - You are doing some optimization (like (A (B C)) gets flattened to (A > B C) etc.) in the parse analysis phase. I think doing that kind of > optimization should be done in the optimizer/planner. Because with > your patch a deparsed query (as shown by pg_get_viewdef()) looks > different from what user inputs. > I completely agree that those optimizations belong in the optimizer/planner phase. I intentionally placed them in the parse analysis phase for now to make debugging easier during this initial development stage. Once the logic is stabilized, I will move them to the planner as you suggested to ensure proper deparsing. > - If you add files to src/backend/parser, it should be noted in > src/backend/parser/README. > > - It would be noce to update typedefs patch if you add new typedefs. > Thank you for pointing those out. I had overlooked the README in src/backend/parser, and I will make sure to update it along with the typedefs patch in my next submission. Best regards, Henson
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