PostgreSQL 模式匹配

PostgreSQL的正則表達式是使用 Henry Spencer 寫的一個包來實現(xiàn)的。下面的正則表達式的大部分描述都是從他的手冊頁中逐字拷貝過來的。

正則表達式（RE），在POSIX 1003.2 中定義， 它有兩種形式：擴展的RE或者是ERE（大概地說就是那些在egrep里的）， 基本的RE或者是BRE（大概地說就是那些在ed里的）。PostgreSQL支持兩種形式，并且還實現(xiàn)了一些POSIX標準中沒有但是在類似 Perl 或者 Tcl 這樣的語言中得到廣泛應用的一些擴展。使用了那些非POSIX擴展的 RE叫高級RE， 或者本文檔里說的ARE。ARE 幾乎完全是 ERE 的超集，但是 BRE 有幾個符號上的不兼容（以及更多的限制）。我們首先描述 ARE 和 ERE 形式， 描述那些只適用于 ARE 的特性，然后描述 BRE 的區(qū)別是什么。

一個正則表達式被定義為一個或更多分支，它們之間被|分隔。只要能匹配其中一個分支的東西都能匹配正則表達式。

一個分支是一個或多個量化原子或者約束連接而成。一個原子匹配第一個，然后后面的原子匹配第二個， 以此類推；一個空分支匹配空串。

一個量化原子是一個原子， 后面可能跟著一個量詞。沒有量詞的時候，它匹配一個原子， 有量詞的時候，它可以匹配若干個原子。一個原子可以是在表 9.17里面顯示的任何可能。 可能的量詞和它們的含義在表 9.18里顯示。

一個約束匹配一個空串，但只是在滿足特定條件下才匹配。 約束可以在能夠使用原子的地方使用，只是它不能跟著量詞。簡單的約束在表 9.19里顯示； 更多的約束稍后描述。

RE 不能以反斜線（\）結尾。

使用{...}的形式被稱作范圍。 一個范圍內(nèi)的數(shù)字m和n都是無符號十進制整數(shù)， 允許的數(shù)值從 0 到 255（包含）。

非貪婪的量詞（只在 ARE 中可用）匹配對應的正常 （貪婪）模式，區(qū)別是它尋找最少的匹配，而不是最多的匹配。詳見第 9.7.3.5 節(jié)。

Lookahead 和 lookbehind 約束不能包含后引用 （參閱第 9.7.3.3 節(jié)），并且其中的所有圓括號 都被認為是非捕獲的。

方括號表達式是一個包圍在[]中的字符列表。它通常匹配列表中的任意單個字符（但見下文）。 如果列表以^開頭，它匹配任意單個不在該列表參與部分中的字符。如果該列表中兩個字符用-隔開， 那它就是那兩個字符（包括在內(nèi)）之間的所有字符范圍的縮寫，例如，在 ASCII中[0-9]匹配任何十進制數(shù)字。兩個范圍共享一個端點是非法的，例如，a-c-e。范圍與字符集關系密切， 可移植的程序應該避免依靠它們。

想在列表中包含文本]，可以讓它做列表的首字符（如果使用了^，需要放在其后）。 想在列表中包含文本-，可以讓它做列表的首字符或者尾字符，或者一個范圍的第二個端點。 想在列表中把文本-當做范圍的起點， 把它用[.和 .]包圍起來，這樣它就成為一個排序元素（見下文）。 除了這些字符本身、一些用[的組合（見下段）以及逃逸（只在 ARE 中有效）以外，所有其它特殊字符 在方括號表達式里都失去它們的特殊含義。特別是，在 ERE 和 BRE 規(guī)則下\不是特殊的， 但在 ARE 里，它是特殊的（引入一個逃逸）。

在一個方括號表達式里，一個排序元素（一個字符、一個被當做一個單一字符排序的多字符序列或者一個表示上面兩種情況的排序序列名稱） 包含在[.和.]里面的時候表示該排序元素的字符序列。該序列被當做該方括號列表 的一個單一元素。這允許一個包含多字符排序元素的方括號表達式去匹配多于一個字符，例如，如果排序序列包含一個ch排序元素， 那么 RE [[.ch.]]*c匹配chchcc的頭五個字符。

在方括號表達式里，包圍在[=和=]里的排序元素是一個等價類， 代表等效于那一個的所有排序元素的字符序列，包括它本身（如果沒有其它等效排序元素，那么就好象封裝定界符是[.和 .]）。例如，如果o和 ^是一個等價類的成員，那么[[=o=]]、[[=^=]]和[o^]都是同義的。一個等價類不能是一個范圍的端點。

在方括號表達式里，在[:和:]里面封裝的字符類的名字代表屬于該類的所有字符的列表。 字符類不能作為范圍的端點使用。POSIX標準定義了這些字符類的名稱： alnum (字符和數(shù)字), alpha (字符), blank(空格和制表符tab), cntrl (控制符), digit (數(shù)位數(shù)), graph (空格除外可打印字符), lower (小寫字母), print (包含空格可打印字符), punct (標點符號), space(空白), upper (大寫字母), 和 xdigit (十六進制數(shù)). 對于7位ASCII字符集中的字符來說，這些標準字符類的行為在不同平臺上一般是一致的。一個給定的非ASCII字符是否被認為屬于這些類別中的一個，取決于正則表達式函數(shù)或運算符使用的collation（見第 23.2 節(jié)），或者默認情況下取決于數(shù)據(jù)庫的LC_CTYPE locale設置（見第 23.1 節(jié)）。非ASCII字符的分類在不同的平臺上會有不同的分類，即使是在類似命名的locale中也是如此。 (但C locale從不認為任何非ASCII字符屬于上述任何一類)。除了這些標準字符類之外， PostgreSQL定義了ascii字符類，它完全包含7位ASCII字符集。

方括號表達式里有兩個特例：方括號表達式[[:<:]]和[[:>:]]是約束，分別匹配一個單詞開頭和結束的空串。 單詞定義為一個單詞字符序列，前面和后面都沒有其它單詞字符。單詞字符是一個alnum字符（和如上所述POSIX字符類中定義的一樣） 或者一個下劃線。這是一個擴展，兼容 POSIX1003.2， 但那里面并沒有說明， 而且在準備移植到其他系統(tǒng)里去的軟件里一定要小心使用。通常下文描述的約束逃逸更好些（它們并非更標準，但是更容易鍵入）。

逃逸是以\開頭，后面跟著一個字母數(shù)字字符得特殊序列。 逃逸有好幾種變體：字符項、類縮寫、約束逃逸以及后引用。在 ARE 里， 如果一個\后面跟著一個字母數(shù)字，但是并未組成一個合法的逃逸， 那么它是非法的。在 ERE 中沒有逃逸：在方括號表達式之外，一個后面跟著字母數(shù)字字符的\只是表示該字符是一個普通的字符，而且在一個方括號表達式里， \是一個普通的字符（后者實際上在 ERE 和 ARE 不兼容）。

字符項逃逸用于便于我們在 RE 中聲明那些不可打印的或其他習慣的字符。它們顯示在表 9.20中。

類縮寫逃逸用來提供一些常用的字符類縮寫。它們顯示在表 9.21中。

約束逃逸是一個約束，如果滿足特定的條件，它匹配該空串。它們顯示在表 9.22中。

后引用（\n）匹配數(shù)字\n指定的被前面的圓括號子表達式匹配的同一個串 （參閱表 9.23）。例如， ([bc])\1匹配bb或者cc， 但是不匹配bc或者cb。RE 中子表達式必須完全在后引用前面。子表達式以它們的先導圓括號的順序編號。非捕獲圓括號并不定義子表達式。

十六進制位是0-9、a-f和A-F。八進制位是0-7。

指定 ASCII 范圍（0–127）之外的值的數(shù)字字符項轉義的含義取決于數(shù)據(jù)庫編碼。 當編碼是 UTF-8 時，轉義值等價于 Unicode 代碼點，例如 \u1234表示字符U+1234。對于其他多字節(jié)編碼， 字符項轉義通常只是指定該字符的字節(jié)值的串接。如果該轉義值不對應數(shù)據(jù)庫編碼 中的任何合法字符，將不會發(fā)生錯誤，但是它不會匹配任何數(shù)據(jù)。

字符項逃逸總是被當作普通字符。例如，\135是 ASCII 中的]， 但\135并不終止一個方括號表達式。

在方括號表達式里，\d、\s和\w會失去它們的外層方括號，而\D、\S和 \W是非法的（也就是說，例如[a-c\d]等效于 [a-c[:digit:]]。同樣[a-c\D]等效于 [a-c^[:digit:]]的，也是非法的）。

一個詞被定義成在上面[[:<:]]和[[:>:]]中的聲明。在方括號表達式里，約束逃逸是非法的。

除了上面描述的主要語法之外，還有幾種特殊形式和雜項語法。

如果一個 RE 以***:開頭，那么剩下的 RE 都被當作 ARE（這在PostgreSQL中通常是無效的，因為 RE 被假定為 ARE，但是如果 ERE 或 BRE 模式通過flags參數(shù)被指定為一個正則表達式函數(shù)時，它確實能產(chǎn)生效果）。如果一個 RE 以***=開頭， 那么剩下的 RE 被當作一個文本串，所有的字符都被認為是一個普通字符。

一個 ARE 可以以嵌入選項開頭：一個序列(?xyz)（這里的xyz是一個或多個字母字符）聲明影響剩余 RE 的選項。 這些選項覆蓋任何前面判斷的選項 — 特別地，它們可以覆蓋一個正則表達式操作符隱含的大小寫敏感的行為，或者覆蓋 flags 參數(shù)中的正則表達式函數(shù)?？捎玫倪x項字母在表 9.24中顯示。注意這些同樣的選項字母也被用在正則表達式函數(shù)的flags參數(shù)中。

嵌入選項在)終止序列時發(fā)生作用。它們只在 ARE 的開始處起作用 （在任何可能存在的***:控制器后面）。

除了通常的（緊）RE 語法（這種情況下所有字符都有效）， 還有一種擴展語法，可以通過聲明嵌入的x選項獲得。在擴展語法里，RE 中的空白字符被忽略，就像那些在#和其后的新行（或 RE 的末尾）之間的字符一樣。這樣就允許我們給一個復雜的 RE 分段和注釋。不過這個基本規(guī)則有三種例外：

為了這個目的，空白是空格、制表符、新行和任何屬于空白字符類的字符。

最后，在 ARE 里，方括號表達式外面，序列(?#ttt)（其中ttt是任意不包含一個))的文本）是一個注釋， 它被完全忽略。同樣，這樣的東西是不允許出現(xiàn)在多字符符號的字符中間的，例如 (?:。這種注釋更像是一種歷史產(chǎn)物而不是一種有用的設施，并且它們的使用已經(jīng)被廢棄；請使用擴展語法來替代。

如果聲明了一個初始的***=控制器，那么所有這些元語法擴展都不能使用，因為這樣表示把用戶輸入當作一個文字串而不是 RE 對待。

在 RE 可以在給定串中匹配多于一個子串的情況下， RE 匹配串中最靠前的那個子串。如果 RE 可以匹配在那個位置開始 的多個子串，要么是取最長的子串，要么是最短的，具體哪種， 取決于 RE 是貪婪的還是非貪婪的。

一個 RE 是否貪婪取決于下面規(guī)則：

上面的規(guī)則所描述的貪婪屬性不僅僅適用于獨立的量化原子， 而且也適用于包含量化原子的分支和整個 RE。這里的意思是， 匹配是按照分支或者整個 RE 作為一個整體匹配最長或者最短的可能子串。 一旦整個匹配的長度確定，那么匹配任意特定子表達式的部分就基于該子表達式的貪婪屬性進行判斷，在 RE 里面靠前的子表達式的優(yōu)先級高于靠后的子表達式。

一個相應的例子：

SELECT SUBSTRING('XY1234Z', 'Y*([0-9]{1,3})');
結果：123
SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
結果：1

在第一個例子里，RE 作為整體是貪婪的，因為Y*是貪婪的。它可以匹配從Y開始的東西，并且它匹配從這個位置開始的最長的串， 也就是，Y123。輸出是這里的圓括號包圍的部分，或者說是123。在第二個例子里， RE 總體上是一個非貪婪的 RE，因為Y*?是非貪婪的。它可以匹配從 Y開始的最短的子串，也就是說Y1。子表達式[0-9]{1,3}是貪婪的，但是它不能修改總體匹配長度的決定； 因此它被迫只匹配1。

簡而言之，如果一個 RE 同時包含貪婪和非貪婪的子表達式，那么總的匹配長度要么是盡可能長，要么是盡可能短，這取決于給整個 RE 賦予的屬性。給子表達式賦予的屬性只影響在這個匹配里，各個子表達式之間相互允許“吃掉”的多少。

量詞{1,1}和{1,1}?可以分別用于在一個子表達式 或者整個 RE 上強制貪婪或者非貪婪。當需要整個 RE 具有不同于從其元素中 推導出的貪婪屬性時，這很有用。例如，假設我們嘗試將一個包含一些數(shù)字的 字符串分隔成數(shù)字以及在它們之前和之后的部分，我們可能會嘗試這樣做：

SELECT regexp_match('abc01234xyz', '(.*)(\d+)(.*)');
Result: {abc0123,4,xyz}

這不會有用：第一個.*是貪婪的，因此它會“吃掉”盡可能多的字符而留下\d+去匹配在最后一個可能位置上的最 后一個數(shù)字。我們可能會通過讓它變成非貪婪來修復：

SELECT regexp_match('abc01234xyz', '(.*?)(\d+)(.*)');
Result: {abc,0,""}

這也不會有用：因為現(xiàn)在 RE 作為整體來說是非貪婪的，因此它會盡快結束 全部的匹配。我們可以通過強制 RE 整體是貪婪的來得到我們想要的：

SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
Result: {abc,01234,xyz}

獨立于 RE 的組件的貪婪性之外控制 RE 的整體貪婪性為處理變長模式提供了 很大的靈活性。

在決定更長或者更短的匹配時，匹配長度是以字符衡量的，而不是排序元素。一個空串會被認為比什么都不匹配長。例如：bb*匹配abbbc的中間三個字符；(week|wee)(night|knights)匹配weeknights的所有十個字符； 而(.*).*匹配 abc的時候，圓括號包圍的子表達式匹配所有三個字符；當(a*)*被拿來匹配bc時，整個 RE 和圓括號 子表達式都匹配一個空串。

如果聲明了大小寫無關的匹配，那么效果就好像所有大小寫區(qū)別在字母表中消失了。如果在多個情況中一個字母以一個普通字符的形式出現(xiàn)在方括號表達式外面，那么它實際上被轉換成 一個包含大小寫的方括號表達式，也就是說，x 變成 [xX]。 如果它出現(xiàn)在一個方括號表達式里面，那么它的所有大小寫的同族都被加入 方括號表達式中，也就是說，x變成[xX]。當它出現(xiàn)在一個方括號表達式內(nèi)時，它的所有大小寫副本都被加入到方括號表達式中，例如， [x]會變成[xX]，而[^x]會變成[^xX]。

如果指定了新行敏感的匹配，.和使用^的方括號表達式 將永遠不會匹配新行字符（這樣，匹配就絕對不會跨越新行，除非 RE 顯式地安排了這樣的情況）并且^和$除了分別匹配串開頭和結尾之外，還將分別匹配新行后面和前面的空串。但是 ARE 逃逸\A和 \Z仍然只匹配串的開頭和結尾。

如果指定了部分新行敏感的匹配，那么它影響.和方括號表達式， 這個時候和新行敏感的匹配一樣，但是不影響^和$。

如果指定了逆新行敏感匹配，那么它影響^和$，其作用和在新行敏感的匹配里一樣，但是不影響.和方括號表達式。這個并不是很有用，只是為了滿足對稱性而提供的。

在這個實現(xiàn)里，對 RE 的長度沒有特別的限制。但是，那些希望高移植性的程序應該避免使用長度超過 256 字節(jié)的 RE，因為 POSIX 兼容 的實現(xiàn)可以拒絕接受這樣的 RE。

ARE 實際上和 POSIX ERE 不兼容的唯一的特性是在方括號表達式里\并不失去它特殊的含義。所有其它 ARE 特性都使用在 POSIX ERE 里面是非法或者是未定義、未聲明效果的語法；指示器的***就是在 POSIX 的 BRE 和 ERE 之外的語法。

許多 ARE 擴展都是從 Perl 那里借來的（但是有些被做了修改來清理它們），以及一些 Perl 里沒有出現(xiàn)的擴展。要注意的不兼容性包括\b、\B、對結尾的新行缺乏特別的處理、對那些被新行敏感匹配的東西附加的補齊方括號表達式、在 lookahead/lookbehind 約束里對圓括號和后引用的限制以及最長/最短 匹配（而不是第一匹配）的語義。

PostgreSQL 7.4 之前的版本中識別的 ARE 和 ERE 語法存在兩個非常明顯的不兼容：

BREs 在幾個方面和 ERE 不太一樣。在 BRE 中，|、+和?都是普通字符并且沒有與它們功能等價的東西。范圍的定界符是\{和\}， 因為 {和 }本身是普通字符。嵌套的子表達式的圓括號是\(和\)，因為(和)自身是普通字符。除非在 RE 開頭或者是圓括號子表達式開頭，^都是一個普通字符。 除非在 RE 結尾或者是圓括號子表達式的結尾， $是一個普通字符。如果*出現(xiàn)在 RE 開頭或者是圓括號封裝的子表達式開頭 （前面可能有^），那么它是個普通字符。最后，可以用單數(shù)字的后引用，\<和\>分別是[[:<:]]和 [[:>:]]的同義詞；在 BRE 中沒有其它可用的逃逸。

從SQL:2008開始，SQL標準中包含了一個LIKE_REGEX操作符，它根據(jù)XQuery正則表達式標準執(zhí)行模式匹配。 PostgreSQL還沒有實現(xiàn)這個操作符，但是你可以使用regexp_match()函數(shù)獲得非常類似的行為，因為XQuery正則表達式非常接近于上面描述的ARE語法。

與現(xiàn)有的基于POSIX的 正則表達式功能和XQuery正則表達式包括。