Re: Row pattern recognition

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

In response to

Responses

Browse pgsql-hackers by date

  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