パターンマッチPostgreSQLには、パターンマッチを行うに際して3つの異なった手法があります。TO演算子(SQL:1999で追加されました)、およびPOSIX様式の正規表現です。基本の「この文字列はこのパターンに一致するか?」を別としても、一致した部分文字列を取り出したり置換したり、そして一致部分で文字列を分割する関数が用意されています。ヒント上記の手法では検索できないようなパターンマッチが必要な場合は、PerlもしくはTclでユーザ定義関数を作成することを検討してください。注意ほとんどの正規表現検索はとても速く実行されますが、正規表現は処理するのに任意の時間とメモリを使う可能性があります。悪意のあるソースから正規表現検索パターンを受け取ることに用心してください。しなければならないのであれば、文のタイムアウトを強制するのが賢明です。TOパターンを使う検索は同様のセキュリティ問題を抱えています。LIKE検索は、他の2つの方法よりずっと単純ですので、悪意があるかもしれないパターンのソースで使うのにはより安全です。この3種類のパターンマッチング演算子はどれも非決定的照合順序をサポートしていません。必要なら、この制限事項に対応するために別の照合順序を式に適用してください。escape-character]LIKE式は供給されたpatternにstringが一致すれば真を返します。LIKE式はLIKE式が真を返す場合には偽を返し、その逆もまた同じです。pattern)とも表現できます。)patternがパーセント記号もしくはアンダースコアを含んでいない場合patternは自身の文字列そのものです。この場合LIKE式は等号演算子のように振舞います。patternの中にあるアンダースコア(_)は任意の一文字との一致を意味し、パーセント記号(%)は0文字以上の並びとの一致を意味します。falseLIKEによるパターン一致は常に文字列全体に対して行われます。従って、文字列内の任意位置における並びと一致させたい場合には、パーセント記号を先頭と末尾に付ける必要があります。他の文字の一致に使用するのではなく、アンダースコアやパーセント記号そのものを一致させたい場合には、patternの中のそれぞれのアンダースコアとパーセント記号の前にエスケープ文字を付けなければなりません。デフォルトのエスケープ文字はバックスラッシュですが、ESCAPE句で他の文字を指定することができます。エスケープ文字そのものを一致させるにはエスケープ文字を2つ書きます。注記standard_conforming_stringsパラメータをoffにしている場合、リテラル文字列定数に記述するバックスラッシュを二重にする必要があります。詳細は4.1.2.1を参照してください。''と記述することでエスケープ文字を選択しないことも可能です。これにより、事実上エスケープ機構が働かなくなります。パターン内のアンダースコアおよびパーセント記号の特別な意味を解除することはできなくなります。SQL標準によれば、ESCAPEを省略することは(デフォルトがバックスラッシュとなるのではなく)エスケープ文字が存在しないことを意味します。長さゼロのESCAPEは使用できません。この点でPostgreSQLは少し非標準な振る舞いをします。現在のロケールに従って大文字小文字を区別しない一致を行うのであれば、LIKEの代わりにILIKEキーワードを使うことができます。これは標準SQLではなく、PostgreSQLの拡張です。~~演算子はLIKE式と等価で、~~*はILIKEに対応します。ILIKEを表す!~~および!~~*演算子があります。これら全ての演算子はPostgreSQL固有のものです。パーサは実際にはLIKEなどをこれらの演算子に変換するため、こうした演算子名はEXPLAINの出力などで見ることができます。ILIKE句は一般にPostgreSQLの構文上は演算子として扱われます。ANY(副問い合わせ)構文で使用できます。ESCAPE句はこれには含むことはできません。状況によっては背後の演算子名を代わりに使わなければならない場合もあります。文字列の先頭からの開始が必要なだけのケースであれば、接頭辞演算子^@とそれに対応するstarts_with関数もあります。TO演算子は、そのパターンが与えられた文字列に一致するかどうかにより、真もしくは偽を返します。これは、標準SQLの正規表現定義を使用してパターンを解釈するという点以外は、LIKEに類似しています。SQLの正規表現は、LIKE表記と一般的な(POSIX)正規表現の表記とを混ぜ合わせたようなものになっています。TO演算子は、そのパターンが文字列全体に一致した場合のみ真を返します。これは、パターンが文字列の一部分であっても一致する、一般的な正規表現の動作とは異なっています。TOでは、%および_を、それぞれ任意の文字列および任意の単一文字を意味するワイルドカード文字として使用します(これらは、POSIX正規表現での.*および.に相当します)。TOでは、以下のようにPOSIX正規表現から取り入れたパターンマッチメタ文字もサポートしています。|は、二者択一(2つの選択肢のうちいずれか)を意味します。*は、直前の項目の0回以上の繰り返しを意味します。+は、直前の項目の1回以上の繰り返しを意味します。?は、直前の項目の0回もしくは1回の繰り返しを意味します。{m}は、直前の項目の正確なm回の繰り返しを意味します。{m,}は、直前の項目のm回以上の繰り返しを意味します。{m,n}は、直前の項目のm回以上かつn回以下の繰り返しを意味します。丸括弧()は、項目を1つの論理項目にグループ化することができます。大括弧式[...]は、POSIX正規表現と同様に文字クラスを指定します。TOではピリオド(.)はメタ文字ではないことに注意してください。LIKEと同様、バックスラッシュは全てのメタ文字の特殊な意味を無効にします。''と書くことにより、エスケープ機能を無効にすることもできます。SQL標準によれば、ESCAPEは(デフォルトがバックスラッシュとなるのではなく)エスケープ文字が存在しないことを意味します。長さゼロのESCAPEは使用できません。この点でPostgreSQLは少し非標準な振る舞いをします。他の非標準の拡張としては、エスケープ文字に続く文字あるいは数字を用いてPOSIX正規表現で定義されたエスケープシーケンスへのアクセスを提供するというのがあります。9.22を参照してください。false3つのパラメータを持つsubstring関数を使用して、SQL正規表現パターンに一致する部分文字列を取り出すことができます。標準SQLの構文にしたがって、この関数は次のように書くことができます。escape-character)あるいは今では廃れたSQL:1999の構文を使って次のように書くことができます。escape-character)あるいは単なる3引数関数として次のように書くこともできます。TOと同様、指定したパターンがデータ文字列全体に一致する必要があります。一致しない場合、関数は失敗し、NULLを返します。マッチするデータのうちの対象とする部分文字列に対応するパターンの部分を示すために、エスケープ文字の後に二重引用符(")を繋げたものを2つパターンに含める必要があります。マッチが成功すると、これらの印で括られたパターンの一部に一致するテキストが返されます。エスケープ文字と二重引用符による区切りは実際にはsubstringのパターン引数を3つの独立した正規表現に分割します。3つのセクションのどこかに置いた垂直線(|)はそのセクションにしか影響を及ぼしません。どのパターンにデータ文字列がマッチするかについて曖昧さがある場合は、最初と3番目の正規表現は、可能な最大のテキストではなく、最小のテキストにマッチするものとして定義されます。(POSIX用語では、最初と3番目の正規表現は非貪欲(non-greedy)に強制されます。)SQL標準への拡張として、PostgreSQLは、二重引用符による区切りが一個だけ存在することを許容し、その場合は3番目の正規表現が空として扱われます。二重引用符による区切りがないことも許容し、その場合は最初と3番目の正規表現は空として扱われます。例:#"を使用して返される文字列を区切ります。9.16に、POSIX正規表現を使ったパターンマッチに使用可能な演算子を列挙します。TO演算子よりもさらに強力です。egrep、sed、あるいはawkのような多くのUnixツールはここで解説しているのと類似したパターンマッチ言語を使用しています。正規表現とは文字列の集合(正規集合)の簡略された定義である文字が連なっているものです。ある文字列が正規表現で記述された正規集合の要素になっていれば、その文字列は正規表現にマッチしていると呼ばれます。特殊文字とされているもの以外、パターン文字は文字列と完全にマッチされます。言っても、正規表現はLIKE関数が使用するのとは異なる特殊文字を使用します。LIKE関数のパターンと違って正規表現は、明示的に正規表現が文字列の最初または最後からと位置指定されていない限り文字列内のどの位置でもマッチを行えます。anchoringPOSIXパターン言語について以下により詳しく説明します。pattern)を使用して、POSIX正規表現パターンにマッチする部分文字列を取り出すことができます。この関数は、マッチするものがない場合にはNULLを返し、ある場合はパターンに最初にマッチしたテキストの一部を返します。(左丸括弧が最初に来るもの)にマッチするテキストの一部が返されます。この例外を起こさずにパターン中に丸括弧を使用したいのであれば、常に正規表現全体を丸括弧で囲むことができます。パターン内の抽出対象の部分文字列より前に丸括弧が必要な場合、後述の捕捉されない丸括弧を参照してください。oregexp_replace関数は、POSIX正規表現パターンにマッチする部分文字列を新規テキストと置換します。patternにマッチしない場合は、source文字列がそのまま返されます。マッチすると、マッチ部分文字列をreplacement文字列で置換したsource文字列が返されます。replacement文字列に\n(nは1から9までの数字)を入れて、パターン内のn番目の丸括弧つき部分表現にマッチする元の部分文字列を挿入することができます。\&を入れて、パターン全体とマッチする部分文字列を挿入することもできます。置換テキスト内にバックスラッシュそのものを挿入する必要がある時は\\と記述します。flagsパラメータは、関数の動作を変更するゼロもしくはそれ以上の1文字フラグを含むオプションのテキスト文字列です。フラグiは大文字小文字を区別しないマッチを指定する一方、フラグgは、最初にマッチしたもののみではなく、それぞれマッチした部分文字列の置換を指定します。9.24に記述されています。fooXarYXazYregexp_match関数はPOSIX正規表現パターンを文字列にマッチさせた結果、捕捉された最初の部分文字列のテキスト配列を返します。])の構文になります。マッチするものがなければ、結果はNULLとなります。マッチする部分があり、かつpatternが丸括弧で括られた部分文字列を含まない場合、結果はパターン全体にマッチする部分文字列を含む単一要素のテキスト配列となります。マッチする部分があり、かつpatternが丸括弧で括られた部分文字列を含む場合、結果はテキスト配列で、そのn番目の要素はpatternのn番目に丸括弧で括られた部分文字列にマッチする部分文字列となります(「捕捉されない」丸括弧は数えません。詳細は以下を参照してください)。flagsパラメータは、関数の動作を変更するゼロもしくは複数の単一文字フラグを含むオプションのテキスト文字列です。9.24に記載されています。row)マッチするときはマッチする部分文字列全体、マッチしないときはNULLを返したいというよくあるケースは、以下のように書くことができます。row)regexp_matches関数はPOSIX正規表現パターンを文字列にマッチさせた結果、捕捉された部分文字列のテキスト配列の集合を返します。構文はregexp_matchと同じです。この関数は、マッチするものがないときは行を返しませんが、マッチするものがあり、gフラグが指定されていないときは1行だけ、マッチするものがN個あり、gフラグが指定されているときはN行を返します。返される各行は上でregexp_matchについて説明したのと全く同じで、マッチする部分文字列全体、またはpatternの丸括弧で括られた部分文字列にマッチする部分文字列を含むテキスト配列です。9.24に示すすべてのフラグに加え、最初のマッチだけでなくすべてのマッチを返すgを受け付けます。rows)ヒント最初にマッチするものだけが必要なときはregexp_match()を使う方がより簡単で効率的ですから、regexp_matches()はほとんどの場合gフラグを指定して使われるでしょう。regexp_match()はPostgreSQLのバージョン10以上でのみ利用できます。古いバージョンを使う時によくある手法は、以下の例のように、副SELECTの中にregexp_matches()の呼び出しを入れることです。tab;これはregexp_match()と同じく、マッチするものがあればテキスト配列を生成し、マッチしなければNULLとなります。副SELECTを使わなければ、マッチするものがないテーブル行については問い合わせの出力が生成されず、多くの場合に期待される動作と異なります。regexp_split_to_table関数はPOSIX正規表現パターンを区切り文字として使用し、文字列を分割します。])の構文になります。patternにマッチしない場合、関数はstringを返します。少なくともひとつのマッチがあれば、それぞれのマッチに対して関数は最後のマッチの終わり(あるいは文字列の始め)から最初のマッチまでのテキストを返します。マッチしなくなると最後のマッチの終わりから文字列の最後までテキストを返します。flagsパラメータは、関数の動作を変更するゼロもしくは複数の単一文字フラグを含むオプションのテキスト文字列です。9.24で記載されているフラグをサポートします。regexp_split_to_array関数は、regexp_split_to_arrayがその結果をtext配列で返すことを除いて、regexp_split_to_tableと同じ動作をします。])の構文になります。パラメータはregexp_split_to_tableのものと同じです。rows)最後の例が明らかにしているように、regexp分割関数は文字列の最初あるいは終わり、もしくは前のマッチの直後に発生する長さを持たないマッチを無視します。regexp_matchおよびregexp_matchesで実装されたregexpマッチの厳格な定義にこれは相容れませんが、実務上は最も使い勝手の良い動作です。Perlのような他のソフトウェアシステムも似たような定義を使用します。Spencerにより書かれたソフトウェアパッケージを使用して実装されています。以下に説明する正規表現の多くの部分は同氏のマニュアルから一字一句複製したものです。1003.2の定義によると、正規表現(RE)には2つの形式があるとされます。拡張REもしくはERE(大まかにいってegrepに代表されるもの)、および基本REもしくはBRE(大まかにいってedに代表されるもの)です。PostgreSQLは両方の形式をサポートし、さらに、POSIX標準にはないけれどもPerlやTclなどのプログラミング言語で利用できることから広く使用されるようになった、いくつかの拡張もサポートしています。本書では、非POSIX拡張を使用したREを高度なREもしくはAREと呼びます。AREはEREの正確な上位セットですが、BREとは複数の記法上の非互換な点があります(さらに非常に多くの制限が課されています)。AREとERE形式について説明し、そして、AREにのみ適用される機能の注意を、さらにBREとの違いについて説明します。注記PostgreSQLは常に、まず正規表現はARE規則に従うと推測します。REパターンの前に、9.7.3.4に記載されているような埋め込みオプションを追加することにより、より限られたERE、あるいはBRE規則を選択することができます。これは、POSIX1003.2の規則を正確に期待しているアプリケーションとの互換性に関して有用です。正規表現は|で区切られた、1つまたは複数のブランチとして定義されます。ブランチのいずれか1つにマッチすればマッチしたことになります。ブランチはゼロ個以上の量化アトムもしくは制約の連結です。最初のものにマッチに、次に第2番目のものにマッチを、というふうにマッチします。空のブランチは空文字列にマッチします。量化アトムとは、単一の量指定子が後ろに付くアトムのことです。量指定子がないと、アトムにマッチするものがマッチしたことになります。量指定子がある場合、アトムとのマッチが何回あるかでマッチしたことになります。9.17に示したもののいずれかを取ることができます。9.18に設定可能な量指定子とその意味を示します。制約は空文字に、特定の条件に合う場合のみにマッチします。アトムを使用できるところには制約を使用することができます。その後に量指定子を付けることはできません。後で他のいくつかの制約を説明します。任意の正規表現で、)reとのマッチに適合するもです。マッチは可能である報告用と意味づけられます。マッチは報告用と意味づけられません。任意の1文字にマッチします。(詳細は9.7.3.2を参照してください)。(ここでkは英数字以外です。)普通の文字として指定した文字にマッチします。\\はバックスラッシュ文字です。(おそらく他の文字が後に続きます)。(AREのみ、EREとBREではこれはcにマッチします)。直後に数字以外がある場合、左中括弧{にマッチします。直後に数字が続く場合、bound(後述)の始まりです。ここでxは他に意味を持たない1文字です。REはバックスラッシュ\を終端とすることはできません。注記もしstandard_conforming_stringsパラメータをoffにしていた場合、リテラル文字列定数に記述するバックスラッシュは2倍必要となります。詳細は4.1.2.1を参照してください。アトムのm個以上n以下の並びにマッチ。mはnを超えることはできません。{m,n}の最短マッチを行うバージョン{...}を使用する形式はバウンドとして知られています。バウンド内のmとnという数は符号なし10進整数であり、0以上255以下の値を取ることができます。最短マッチを行う量指定子(AREのみで使用可能)は、対応する通常の(欲張りの)ものと同じものにマッチしますが、最大のマッチではなく最小のマッチを取ります。詳細は9.7.3.5を参照してください。量指定子の直後に量指定子を続けることはできません。量指定子から式や副式を始めることはできず、また、^や|の直後に付けることもできません。先行肯定検索は、reにマッチする部分文字列が始まる任意の場所にマッチします(AREのみ)。先行否定検索は、reにマッチしない部分文字列が始まる任意の場所にマッチします(AREのみ)。後方肯定検索はreにマッチする部分文字列が終わる任意の場所にマッチします(AREのみ)。後方否定検索reにマッチしない部分文字列が終わる任意の場所にマッチします(AREのみ)。先行検索制約および後方検索制約には後方参照(9.7.3.3を参照)を含めることはできません。その中の括弧は全て取り込むものではないとみなされます。ブラケット式ブラケット式とは、[]内の文字のリストです。通常これはそのリスト内の任意の1文字にマッチします(しかし、以降を参照してください)。リストが^から始まる場合、そのリストの残りにはない任意の1文字にマッチします。リスト内の2文字が-で区切られていた場合、これは2つ(を含む)の間にある文字範囲全体を表す省略形となります。ASCIIにおける[0-9]は全ての数字にマッチします。a-c-eといった、終端を共有する2つの範囲は不正です。範囲は並びの照合順に非常に依存しています。移植予定のプログラムではこれに依存してはなりません。このリストに]そのものを含めるには、それを先頭文字(もしそれが使用されれば^の後)にしてください。-そのものを含めるには、それを先頭もしくは末尾の文字とするか、範囲の2番目の終端としてください。-を範囲の最初の終端で使用するには、[.と.]でそれを囲み、照合要素(後述)にしてください。これら文字と、[(次段落を参照)のなんらかの組み合わせ、およびエスケープ(AREのみ)を例外として、他の全ての特殊文字はブラケット式内では特殊な意味を持ちません。\はEREとBRE規則に従う場合は特別でなくなります。AREでは(エスケープの始まりとして)特別な意味を持ちます。ブラケット式内に、照合要素(文字、単一文字であるかのように照合する複数文字の並び、もしくはそれぞれの照合並びの名前)が[.と.]の間にあると、その照合要素の文字の並びを意味します。この並びはブラケット式のリストの一要素として取り扱われます。このことにより、ブラケット式は要素を照合する複数文字を含むブラケット式を1文字以上にマッチさせることができます。照合並びがch照合要素を含む場合、正規表現[[.ch.]]*cはchchccという文字の最初の5文字にマッチします。今のところ、PostgreSQLは複数文字照合要素をサポートしません。この情報は将来の振舞いの可能性を説明したものです。ブラケット式内の[=と=]の間に照合要素は同値クラスです。全ての照合要素の文字の並びが自身を含むものと等価であることを示します。(他に等価な照合要素がある場合、[.と.]で囲まれたかのように扱われます。[[=o=]]、[[=^=]]および[o^]が全て同意語であれば、oと^は同値クラスのメンバです。同値クラスは範囲の終端にはなりません。ブラケット式内では、[:と:]の間にある文字クラスの名称は、そのクラスに属する全ての文字のリストを意味します。文字クラスは範囲の終端位置としては使用できません。POSIX標準は以下の文字クラス名を定義しています。alnum(文字と数字)、alpha(文字)、blank(空白とタブ)、cntrl(制御文字)、digit(数字)、graph(空白以外の印字可能文字)、lower(小文字)、print(空白を含む印字可能文字)、punct(句読点)、space(空白)、upper(大文字)、xdigit(16進数)です。ASCII集合の範囲であれば一般にどのプラットフォームでも同じです。与えられた非ASCII文字がこれらの文字クラスに属すると考えられるかどうかは、正規表現関数または演算子(24.2参照)で使用される照合順、あるいはデフォルトとしてはデータベースのLC_CTYPEロケール(24.1)の設定によります。非ASCII文字の分類は、たとえ似たような名前のロケールであってもプラットフォームによって異なることがありえます。(ただしCロケールでは、すべての非ASCII文字はこれらのクラスのどれにも所属しないものとされます。ASCII集合を正確に含むascii文字クラスが定義されています。ブラケット式には2つの特殊な場合があります。[[:<:]]と[[:>:]]というブラケット式は、先頭と終端の単語がそれぞれ空文字であることにマッチする制約です。単語は、単語文字が前後に付かない単語文字の並びとして定義されます。単語文字とはword文字クラスに所属するすべての文字、すなわちすべての文字、数字、アンダースコアです。1003.2との互換性はありますが、そこでは定義されていない式です。他システムへ移植予定のソフトウェアでの使用には注意が必要です。通常後述の制約エスケープの方がよく使われます。これはもはや標準ではありませんが、入力しやすいものです。正規表現エスケープエスケープとは、\から始まり英数字がその後に続く特殊な並びです。エスケープには、文字エントリ、クラス省略、制約エスケープ、後方参照といった様々な変種があります。\の後に英数字が続くけれども、有効なエスケープを構成しない並びはAREでは不正です。EREにはエスケープはありません。ブラケット式の外側では、\の後に英数字が続く並びは単に普通の文字としてその文字を意味します。ブラケット式の内側では、\は普通の文字です。(後者はEREとARE間の非互換性の1つです。)文字エントリエスケープは非印字文字やRE内でその他の不便な文字の指定を簡略化するために存在します。クラス省略エスケープは、あるよく使用される文字クラスの省略形を提供します。制約エスケープは、指定した条件に合う場合に空文字にマッチする制約をエスケープとして表したものです。9.23を参照してください)。([bc])\1はbbもしくはccにマッチしますが、bcやcbにはマッチしません。REでは副式全体は後方参照の前になければなりません。副式は開括弧の順番で番号付けされます。取り込まない括弧は副式を定義しません。後方参照は参照される副式にマッチした文字列のみを考慮し、そこに含まれる制約は考慮しません。(^\d)\1は22にマッチします。照合順名がESCとなる文字、それに失敗したら、033という8進数値を持つ文字。(ここでxyzは正確に3桁の8進数で、後方参照ではない)その値が0xyzとなる文字16進数の桁とは0-9、a-f、A-Fです。8進数の桁とは0-7です。ASCIIの範囲(0-127)外の値を指定した数字のエントリエスケープは、その意味がデータベースエンコーディングに依存します。エンコーディングがUTF-8の場合、エスケープ値はユニコード符号位置に相当します。\u1234は文字U+1234を意味します。その他のマルチバイトエンコーディングでは、文字エントリエスケープはたいてい文字のバイト値の連結を指定します。エスケープ値がデータベースエンコーディングでのいかなる正当な文字にも対応しない場合、エラーは起こりませんが、いかなるデータにもマッチしません。この文字エントリエスケープは常に普通の文字と解釈されます。\135はASCIIの]となり、\135はブラケット式の終端にはなりません。[[:digit:]]のようなすべての数字にマッチします。[[:space:]]のようなすべての空白文字にマッチします。[[:word:]]のようなすべての単語文字にマッチします。[^[:digit:]]のようなすべての非数字にマッチします。[^[:space:]]のようなすべての非空白文字にマッチします。[^[:word:]]のようなすべての非単語文字にマッチします。クラス省略エスケープはブラケット式の中でも使えますが、上に示した定義はそのコンテキストでは構文的に正しいとは言えません。[a-c\d]は[a-c[:digit:]]と同様です。文字列の先頭にのみマッチします(^との違いについては9.7.3.5を参照してください)。単語の先頭にのみマッチします。単語の末尾にのみマッチします。単語の先頭もしくは末尾にのみマッチします。単語の先頭もしくは末尾以外の場所にのみマッチします。文字列の末尾にのみマッチします($との違いについては9.7.3.5を参照してください)。単語は前述の[[:<:]]と[[:>:]]の規定通りに定義されます。ブラケット式内では制約エスケープは不正です。(ここでmは非ゼロの数です。(ここでmは非ゼロの数です。nnでさらに桁を指定します。mnn10進数値は取り込み括弧の数よりも多くてはなりません。注記8進数の文字エントリエスケープと後方参照の間には曖昧性があります。上でヒントとして示したようにこれは以下の発見的手法で解決されます。先頭の0は常に8進数エスケープを示します。その後に数字が続かない単一の非ゼロ数字は常に後方参照として解釈されます。ゼロから始まらない複数数字の並びは、適切な副式の後にあれば(つまり、その番号が後方参照用の範囲内にあれば)後方参照として解釈されます。なくば、8進数として解釈されます。上述の主構文の他に、特殊な形式や雑多な構文的な機能が使用可能です。REは、2つの特殊な決定子前置詞のどちらかから始まります。REが***:から始まるものであれば、REの残りはAREと解釈されます。(PostgreSQLはREをAREとして推測するため、通常は影響を受けません。正規表現関数に対してflagsパラメータを指定されたEREやBREモードでは影響を受けます。REが***=から始まるものであれば、REの残りは、全ての文字を普通の文字とみなしたリテラル文字列と解釈されます。AREは埋め込みオプションから始められます。(?xyz)という並びで残りのREに影響するオプションを指定します(ここでxyzは1つ以上の英字です)。このオプションは、事前に決定されたオプションを上書きします。正規表現関数に与えられたflagsパラメータにより示される大文字小文字の区別を上書きします。これらの同じオプション文字が、正規表現関数のflagsパラメータで使用されることに注意して下さい。大文字小文字を区別するマッチ(演算子で規定される大文字小文字の区別よりこの指定が優先されます)。大文字小文字を区別しないマッチ(9.7.3.5を参照)(演算子で規定される大文字小文字の区別よりこの指定が優先されます)。拡張構文(後述)埋め込みオプションはその並びの終端)で有効になります。AREの先頭(もし***:決定子があればその後)でのみ利用可能です。全ての文字が意味を持つ、通常の(厳しめの)RE構文に加え、x埋め込みオプションを指定することで利用できる拡張構文があります。拡張構文では、RE内の空白文字は無視され、#とその後の改行(もしくはREの終端)の間の全ての文字も同様です。これにより、段落付けや複雑なREのコメント付けが可能になります。基本規則に対して3つの例外があります。直前に\が付いた空白文字もしくは#は保持されます。ブラケット式内の空白文字もしくは#は保持されます。(?:などの複数文字シンボルでは、空白文字とコメントは不正です。ここでの空白文字とは、空白、タブ、改行、スペース文字クラスに属する文字です。最後に、AREのブラケット式の外側では、(?#ttt)という並びはコメントになります(ここでtttは)を含まない任意のテキストです)。繰り返しになりますが、これは(?:などの複数文字シンボルの文字間では使用できません。したコメントは実用性というより歴史的所産です。そのため、この使用は勧めません。代わりに拡張構文を使用してください。初めに***=決定子が指定され、ユーザの入力がREではなくリテラルとして扱われる場合、これらのメタ構文拡張は使用できません。正規表現マッチ規則REが文字列の中の1つ以上の部分文字列とマッチする場合において、REは最初にマッチが始まった部分文字列とマッチします。その位置からまた1つ以上の部分文字列とマッチした際は、正規表現は最短マッチを行わない(欲張り型)か最短マッチを行う(非欲張り型)かによって、最長マッチもしくは最短マッチの文字列のどちらかにマッチしますREが最長マッチかどうかは以下の規則によって決まります。ほとんどのアトムおよび全ての式は欲張り属性を持ちません(これらは変動する量のテキストにまったくマッチしないからです)。REを括弧で括ることは欲張りかどうかを変更しません。{m}もしくは{m}?といった固定繰り返し数の量指定子を持つ量指定付きアトムは、アトム自身と同一の欲張りさを持ちます(まったく持たない可能性もあります)。他の通常の量指定子({m,n}、mとnが等しい場合も含みます)を持つ量指定付きアトムは欲張り型です(最長マッチを使用します)。他の非欲張り型量指定子({m,n}?、mとnが等しい場合も含みます)を持つ量指定付きアトムは非欲張り型です(最短マッチを使用します)。最上位レベルの|演算子を持たないREであるブランチは、最初の欲張り属性を持つ量指定付きアトムと同一の欲張り属性を持ちます。|演算子で接続された2つ以上のブランチからなるREは常に欲張り型です。上の規則は、個々の量指定付きアトムだけではなく、量指定付きアトムを複数含むブランチやRE全体の欲張り属性に関連します。ブランチやRE全体が全体として最長または最短の部分文字列にマッチするという方法でマッチ処理が行われます。全体のマッチの長さが決まると、特定の部分式にマッチする部分がその部分式の欲張り属性によって決まります。この時、RE内でより前にある部分式が後にある部分式よりも高い優先度を持ちます。この意味の例を示します。1最初の例では、Y*が欲張り型であるため、REは全体として欲張り型です。マッチはYの位置から始まり、そこから可能な限り最長の文字列にマッチします。出力は括弧で括られた部分、つまり123となります。2番目の例では、Y*?が非欲張り型のため、REは全体として非欲張り型です。マッチはYの位置から始まり、そこから可能な限り最短の文字列にマッチします。部分式[0-9]{1,3}は欲張り型ですが、決定されたマッチする全体の長さを変更することはできません。したがって、強制的に1にマッチすることになります。まとめると、REが欲張り型部分式と非欲張り型部分式の両方を持つ場合、全体のマッチ長はRE全体に割り当てられる属性に応じて、最長マッチ長か最短マッチ長のどちらかになります。部分式に割り当てられた属性は、部分式の中でどれだけの量をその部分式の中で「消費」できるかのみに影響します。{1,1}および{1,1}?量指定子を副式もしくはRE全体に使用して、それぞれ、欲張りか欲張りでないかを強制することが可能です。RE全体に対してはその要素から推論されるものと異なる欲張りさの属性が必要な場合に、これは便利です。例として、数字をいくつか含む文字列を数字とその前後の部分に分けようとしているとします。次のようにしてみるかもしれません。{abc0123,4,xyz}上手くいきませんでした。最初の.*が欲張りで、可能なだけ「消費」してしまい、\d+は最後の可能な場所で最後の数字にマッチします。欲張りでなくすることで直そうとするかもしれません。{abc,0,""}またもや上手くいきませんでした。今度は、REが全体として欲張りでなくなってしまい、できる限り早く全体に渡るマッチを終わらせてしまうからです。RE全体として欲張りにすることで欲しいものが得られます。{abc,01234,xyz}REの全体に渡る欲張りさをその要素の欲張りさと別に制御すれば、可変長のパターンを非常に柔軟に扱えます。マッチが長いか短いかを判断する時には、マッチの長さは照合要素ではなく文字列で測られます。空文字列はまったくマッチする要素がない文字列よりも長いと考えられます。bb*はabbbcの真中の3文字とマッチし、(week|wee)(night|knights)はweeknightsの全ての10文字とマッチし、abcに対して(.*).*がマッチされると、括弧内の部分正規表現は3つの文字全てにマッチし、bcに対して(a*)*がマッチされると、全体のREと括弧内の正規表現は空文字列にマッチします。大文字小文字を区別しないマッチが指定されると、アルファベット文字の大文字小文字の区別がまったくなくなったのと同じ効果を与えます。ブラケット式の外側にアルファベットの大文字小文字が混ざった通常の文字が出てきた場合、例えば、xが[xX]となるように大文字小文字ともにブラケット式に実質的に転換されます。ブラケット式の中に現れた時は、(例えば)[x]が[xX]となり、また[^x]が[^xX]となるように、全ての大文字小文字それぞれの対がブラケット式に追加されます。改行を区別するマッチが指定されると、.と^を使用するブラケット式は(REが明示的に改行を含まない限りマッチが行をまたがらないようにするために)改行文字にマッチしなくなります。^と$はそれぞれ改行直後と直前の空文字列にマッチし、さらに、それぞれ文字列の先頭と末尾にマッチします。AREエスケープの\Aと\Zは、継続して、文字列の先頭と末尾のみにマッチします。文字クラス短縮形\Dと\Wこのモードが何であれ改行にマッチします。14より前では、改行敏感モードのときはこれらは改行にマッチしませんでした。古い挙動で動かすには[^[:digit:]]あるいは[^[:word:]]と書いてください。)部分的に改行を区別するマッチが指定されると、.とブラケット式は改行を区別するマッチを行うようになりますが、^と$は変更されません。部分的に改行を区別する逆マッチが指定されると、^と$は改行を区別するマッチを行うようになりますが、.とブラケット式は変更されません。これはあまり有用ではありません。対称性のために提供されています。本実装ではREの長さに関する制限はありません。移植性を高めたいプログラムでは、256バイトを超えるREを使用すべきではありません。POSIX互換の実装ではそうしたREでは混乱する可能性があります。EREと実質的な非互換性があるのは、\がブラケット式の内側で特殊な意味を失わないという点のみです。効果となる構文を使用しています。決定子の***構文などはBREおよびEREのPOSIX構文にはありません。多くのARE拡張はPerlから拝借したものです。いくつかは整理され、Perlの拡張のいくつかは存在しません。後方参照についての制限、最長/最短(最初にマッチするではなく)マッチのセマンティクスがあります。基本正規表現BREはEREといくつかの面において異なります。BREにおいては、|、+、?は普通の文字であり、それらの機能と等価なものはありません。バウンドの区切りは\{と\}であり、{と}自身は普通の文字です。副式を入れ子にするための括弧は\(と\)であり、(と)自身は普通の文字です。^は、REの先頭にある場合や括弧内の副式の先頭の場合を除き、普通の文字です。$は、REの末尾にある場合や括弧内の副式の末尾の場合を除き、普通の文字です。*はREの先頭にある場合や括弧内の副式の先頭にある場合には普通の文字になります(その前に^が付いている可能性もあります)。最後に、1桁の後方参照を使用することができ、また、BREにおいては、\<と\>はそれぞれ[[:<:]]と[[:>:]]と同義です。XQueryとの違い(LIKE_REGEX)SQL:2008以降、SQL標準にはXQuery正規表現標準によるパターンマッチングを行うLIKE_REGEX演算子が含まれています。PostgreSQLは今の所この演算子を実装していませんが、regexp_match()を使ってよく似た振る舞いを得ることができます。XQueryの正規表現は上で述べたARE構文に非常に近いからです。既存のPOSIXベースの正規表現機能とXQueryの正規表現の主な違いには以下のものが含まれます。XQueryの文字クラス減算はサポートされていません。この機能の例としては、[a-z-[aeiou]]のようにして英語の子音のみにマッチさせるというのがあります。XQueryの文字クラス短縮形\c、\C、\i、\Iはサポートされていません。\p{UnicodeProperty}あるいはその逆である\P{UnicodeProperty}を使ったXQueryの文字クラス要素はサポートされていません。9.21参照)のような文字クラスを解釈します。XQueryはこれらのクラスをUnicodeの文字属性を参照してこれらのクラスを決定します。Unicodeルールに従うロケールを使用してのみ同等の振る舞いを得ることができます。SQL標準(XQuery自身ではなく)はPOSIXが提供するより多様な「newline」の亜種を提供しようとしています。NL(\n)だけを改行として考慮します。(U+2028)のようなUnicodeのみの文字も改行として扱うことを求めています。SQLにおいては、.と\sは\r\nを2文字ではなく、1文字として数える必要があります。9.20で示す文字エントリエスケープのうち、XQueryは\n、\r、\tだけをサポートしています。XQueryはブラケット式内の文字クラスとして[:name:]構文をサポートしていません。9.22に記述された制約エスケープもありません。9.7.3.4に記述されたメタ構文形式はXQueryには存在しません。9.24)のオプション文字に関連していますが、同じではありません。iとqオプションは同じように振る舞いますが、その他は違います。XQueryのs(ピリオドが改行にマッチすることを許容する)とm(^と$が改行位置でマッチすることを許容する)フラグは、POSIXのn、p、wフラグと同じ挙動を提供しますが、POSIXのsとmフラグの挙動とは一致しません。ピリオドが改行にマッチするのはPOSIXではデフォルトの挙動ですが、XQueryではそうでないことに留意してください。XQueryのx(パターン中の空白を無視する)フラグはPOSIXの拡張モードフラグとは著しく異なります。POSIXのxフラグは#でパターン中のコメントを始めることもできます。POSIXはバックスラッシュ以降の空白文字を無視しません。