Re: Row pattern recognition
| От | Tatsuo Ishii |
|---|---|
| Тема | Re: Row pattern recognition |
| Дата | |
| Msg-id | 20260217.180053.64368434967157940.ishii@postgresql.org обсуждение |
| Ответ на | Re: Row pattern recognition (Henson Choi <assam258@gmail.com>) |
| Список | pgsql-hackers |
Hi Henson, >> 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. Ok. > To avoid confusion with SQL regex anchors, I suggest we change the > terminology: > > "Anchored pattern" → "Pattern with PREFIX" or "PREFIX-led pattern" I like "Pattern with PREFIX". > "Anchored pattern absorption" → "PREFIX pattern absorption optimization" Looks good. > 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? Yes! Best regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
В списке pgsql-hackers по дате отправления: