Re: Row pattern recognition

Henson Choi <assam258@gmail.com>

From: Henson Choi <assam258@gmail.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com, peter@eisentraut.org, pgsql-hackers@postgresql.org
Date: 2026-02-17T06:44:57Z
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Adjust cross-version upgrade tests for seg_out() fix

  2. Rationalize error comments in partition split/merge tests

  3. Add fast path for foreign key constraint checks

  4. Fix assorted pretty-trivial memory leaks in the backend.

  5. Add temporal FOREIGN KEY contraints

  6. Add trailing commas to enum definitions

  7. Remove obsolete executor cleanup code