| From: | Henson Choi <assam258(at)gmail(dot)com> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Cc: | vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Row pattern recognition |
| Date: | 2026-02-17 06:44:57 |
| Message-ID: | CAAAe_zA8+WfLq=SVNF0omZ5L0g80noGD03tjWy8defLj1-koww@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Tatsuo,
> What do you mean by "Anchored pattern" here? I am asking because R010
> (RPR in Window clause) does not allow to use anchors (^ and $) in
> PATTERN clause.
>
Good catch - the term "anchored pattern" is indeed confusing here.
You're absolutely right that SQL:2023 R010 does not allow regex anchors
(^ and $) in the PATTERN clause.
In this context, I was using "anchored" to mean "a pattern that starts
with a PREFIX element" - not referring to regex anchors at all. The
example "START A+ B" has a PREFIX element (START) that "anchors" the
pattern matching to begin at a specific point.
To avoid confusion with SQL regex anchors, I suggest we change the
terminology:
"Anchored pattern" → "Pattern with PREFIX" or "PREFIX-led pattern"
"Anchored pattern absorption" → "PREFIX pattern absorption optimization"
The optimization issue remains the same: PREFIX elements block the
absorption mechanism, requiring the "shadow path" approach to maintain
O(n) complexity while processing patterns like "START A+ B".
Does this clarification make sense?
Best regards,
Henson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-17 06:58:38 | Re: Our ABI diff infrastructure ignores enum SysCacheIdentifier |
| Previous Message | Tatsuo Ishii | 2026-02-17 06:39:22 | Re: Row pattern recognition |