PostgreSQLの正規表現はHenry Spencerにより書かれたソフトウェアパッケージを使用して実装されています。 以下に説明する正規表現の多くの部分は同氏のマニュアルから一字一句複製したものです。

POSIX 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との違いについて説明します。

正規表現は|で区切られた、1つまたは複数のブランチとして定義されます。 ブランチのいずれか1つにマッチすればマッチしたことになります。

ブランチはゼロ個以上の量化アトムもしくは制約の連結です。 最初のものにマッチに、次に第２番目のものにマッチを、というふうにマッチします。なお、空のブランチは空文字列にマッチします。

量化アトムとは、単一の量指定子が後ろに付くアトムのことです。 量指定子がないと、アトムにマッチするものがマッチしたことになります。 量指定子がある場合、アトムとのマッチが何回あるかでマッチしたことになります。 アトムは、表 9.16に示したもののいずれかを取ることができます。 表 9.17に設定可能な量指定子とその意味を示します。

制約は空文字に、特定の条件に合う場合のみにマッチします。 アトムを使用できるところには制約を使用することができます。ただしその後に量指定子を付けることはできません。 単純な制約を表 9.18に示します。後で他のいくつかの制約を説明します。

REはバックスラッシュ\を終端とすることはできません。

{...}を使用する形式はバウンドとして知られています。 バウンド内のmとnという数は符号なし10進整数であり、0以上255以下の値を取ることができます。

最短マッチを行う量指定子（AREのみで使用可能）は、対応する通常の（欲張りの）ものと同じものにマッチしますが、最大のマッチではなく最小のマッチを取ります。 詳細は9.7.3.5を参照してください。

先行検索制約および後方検索制約には後方参照（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文字にマッチします。

ブラケット式内の[=と=]の間に照合要素は同値クラスです。全ての照合要素の文字の並びが自身を含むものと等価であることを示します。 （他に等価な照合要素がある場合、[.と.]で囲まれたかのように扱われます。） 例えば、[[=o=]]、[[=^=]]および[o^]が全て同意語であれば、oと^は同値クラスのメンバです。 同値クラスは範囲の終端にはなりません。

ブラケット式内では、[:と:]の間にある文字クラスの名称は、そのクラスに属する全ての文字のリストを意味します。 文字クラスは範囲の終端位置としては使用できません。 POSIX標準は以下の文字クラス名を定義しています。 alnum（文字と数字）、alpha（文字）、blank（空白とタブ）、cntrl（制御文字）、digit（数字）、graph（空白以外の印字可能文字）、lower（小文字）、print（空白を含む印字可能文字）、punct（句読点）、space（空白）、upper（大文字）、xdigit（16進数）です。 これらの標準文字クラスの振る舞いは7-bit ASCII集合の範囲であれば一般にどのプラットフォームでも同じです。 与えられた非ASCII文字がこれらの文字クラスに属すると考えられるかどうかは、正規表現関数または演算子（23.2参照）で使用される照合順、あるいはデフォルトとしてはデータベースのLC_CTYPEロケール（23.1)の設定によります。 非ASCII文字の分類は、たとえ似たような名前のロケールであってもプラットフォームによって異なることがありえます。 （ただしCロケールでは、すべての非ASCII文字はこれらのクラスのどれにも所属しないものとされます。） これらの標準クラスに加え、PostgreSQLでは7-bit ASCII集合を正確に含むascii文字クラスが定義されています。

ブラケット式には2つの特殊な場合があります。[[:<:]]と[[:>:]]というブラケット式は、先頭と終端の単語がそれぞれ空文字であることにマッチする制約です。 単語は、単語文字が前後に付かない単語文字の並びとして定義されます。 単語文字とは（上述のPOSIX文字クラスで定義されているように）1つのalnum文字またはアンダースコアです。 これは、POSIX 1003.2との互換性はありますが、そこでは定義されていない式です。ですので、他システムへ移植予定のソフトウェアでの使用には注意が必要です。 通常後述の制約エスケープの方がよく使われます。これはもはや標準ではありませんが、入力しやすいものです。

エスケープとは、\から始まり英数字がその後に続く特殊な並びです。 エスケープには、文字エントリ、クラス省略、制約エスケープ、後方参照といった様々な変種があります。 \の後に英数字が続くけれども、有効なエスケープを構成しない並びはAREでは不正です。 EREにはエスケープはありません。ブラケット式の外側では、\の後に英数字が続く並びは単に普通の文字としてその文字を意味します。ブラケット式の内側では、\は普通の文字です。 （後者はEREとARE間の非互換性の1つです。）

文字エントリエスケープは非印字文字やRE内でその他の不便な文字の指定を簡略化するために存在します。 これらを表 9.19に示します。

クラス省略エスケープは、あるよく使用される文字クラスの省略形を提供します。 これらを表 9.20に示します。

制約エスケープは、指定した条件に合う場合に空文字にマッチする制約をエスケープとして表したものです。 これらを表 9.21に示します。

後方参照（\n）は、直前に括弧で囲まれた副式によってマッチされた、n番目の同一文字列にマッチします（表 9.22を参照してください）。 例えば、([bc])\1はbbもしくはccにマッチしますが、bcやcbにはマッチしません。REでは副式全体は後方参照の前になければなりません。 副式は開括弧の順番で番号付けされます。 取り込まない括弧は副式を定義しません。

16進数の桁とは0-9、a-f、A-Fです。 8進数の桁とは0-7です。

ASCIIの範囲(0-127)外の値を指定した数字のエントリエスケープは、その意味がデータベースエンコーディングに依存します。 エンコーディングがUTF-8の場合、エスケープ値はユニコード符号位置に相当します。例えば、\u1234は文字U+1234を意味します。 その他のマルチバイトエンコーディングでは、文字エントリエスケープはたいてい文字のバイト値の連結を指定します。 エスケープ値がデータベースエンコーディングでのいかなる正当な文字にも対応しない場合、エラーは起こりませんが、いかなるデータにもマッチしません。

この文字エントリエスケープは常に普通の文字と解釈されます。 例えば、\135はASCIIの]となり、\135はブラケット式の終端にはなりません。

ブラケット式内では、\d、\s、および\wはその外側の大括弧を失い、\D、\Sおよび\Wは不正です。 （ですから、例えば[a-c\d]は[a-c[:digit:]]と同じになります。また、[a-c\D]は[a-c^[:digit:]]と同じになり、不正です。）

単語は前述の[[:<:]]と[[:>:]]の規定通りに定義されます。ブラケット式内では制約エスケープは不正です。

上述の主構文の他に、特殊な形式や雑多な構文的な機能が使用可能です。

REは、2つの特殊な決定子前置詞のどちらかから始まります。 REが***:から始まるものであれば、REの残りはAREと解釈されます。 (PostgreSQLはREをAREとして推測するため、通常は影響を受けません。ただし、正規表現関数に対してflagsパラメータを指定されたEREやBREモードでは影響を受けます。) REが***=から始まるものであれば、REの残りは、全ての文字を普通の文字とみなしたリテラル文字列と解釈されます。

AREは埋め込みオプションから始められます。(?xyz)という並びで残りのREに影響するオプションを指定します（ここでxyzは1つ以上の英字です）。 このオプションは、事前に決定されたオプションを上書きします。— 特に、正規表現演算子、もしくは正規表現関数に与えられたflagsパラメータにより示される大文字小文字の区別を上書きします。 使用可能なオプション文字を表 9.23に示します。 これらの同じオプション文字が、正規表現関数のflagsパラメータで使用されることに注意して下さい。

埋め込みオプションはその並びの終端)で有効になります。 AREの先頭（もし***:決定子があればその後）でのみ利用可能です。

全ての文字が意味を持つ、通常の（厳しめの）RE構文に加え、x埋め込みオプションを指定することで利用できる拡張構文があります。 拡張構文では、RE内の空白文字は無視され、#とその後の改行（もしくはREの終端）の間の全ての文字も同様です。 これにより、段落付けや複雑なREのコメント付けが可能になります。 基本規則に対して3つの例外があります。

ここでの空白文字とは、空白、タブ、改行、スペース文字クラスに属する文字です。

最後に、AREのブラケット式の外側では、(?#ttt)という並びはコメントになります（ここでtttは)を含まない任意のテキストです）。 繰り返しになりますが、これは(?:などの複数文字シンボルの文字間では使用できません。 こうしたコメントは実用性というより歴史的所産です。そのため、この使用は勧めません。代わりに拡張構文を使用してください。

初めに***=決定子が指定され、ユーザの入力がREではなくリテラルとして扱われる場合、これらのメタ構文拡張は使用できません。

REが文字列の中の1つ以上の部分文字列とマッチする場合において、REは最初にマッチが始まった部分文字列とマッチします。 その位置からまた1つ以上の部分文字列とマッチした際は、正規表現は最短マッチを行わない（欲張り型）か最短マッチを行う（非欲張り型）かによって、最長マッチもしくは最短マッチの文字列のどちらかにマッチします

REが最長マッチかどうかは以下の規則によって決まります。

上の規則は、個々の量指定付きアトムだけではなく、量指定付きアトムを複数含むブランチやRE全体の欲張り属性に関連します。 つまり、ブランチやRE全体が全体として最長または最短の部分文字列にマッチするという方法でマッチ処理が行われます。 全体のマッチの長さが決まると、特定の部分式にマッチする部分がその部分式の欲張り属性によって決まります。この時、RE内でより前にある部分式が後にある部分式よりも高い優先度を持ちます。

この意味の例を示します。

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

最初の例では、Y*が欲張り型であるため、REは全体として欲張り型です。 マッチはYの位置から始まり、そこから可能な限り最長の文字列にマッチします。つまりY123となります。 出力は括弧で括られた部分、つまり123となります。 2番目の例では、Y*?が非欲張り型のため、REは全体として非欲張り型です。 マッチはYの位置から始まり、そこから可能な限り最短の文字列にマッチします。つまりY1となります。 部分式[0-9]{1,3}は欲張り型ですが、決定されたマッチする全体の長さを変更することはできません。したがって、強制的に1にマッチすることになります。

まとめると、REが欲張り型部分式と非欲張り型部分式の両方を持つ場合、全体のマッチ長はRE全体に割り当てられる属性に応じて、最長マッチ長か最短マッチ長のどちらかになります。 部分式に割り当てられた属性は、部分式の中でどれだけの量をその部分式の中で「消費」できるかのみに影響します。

{1,1}および{1,1}?量指定子を副式もしくはRE全体に使用して、それぞれ、欲張りか欲張りでないかを強制することが可能です。 RE全体に対してはその要素から推論されるものと異なる欲張りさの属性が必要な場合に、これは便利です。 例として、数字をいくつか含む文字列を数字とその前後の部分に分けようとしているとします。 次のようにしてみるかもしれません。

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

上手くいきませんでした。最初の.*が欲張りで、可能なだけ「消費」してしまい、\d+は最後の可能な場所で最後の数字にマッチします。 欲張りでなくすることで直そうとするかもしれません。

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

またもや上手くいきませんでした。今度は、REが全体として欲張りでなくなってしまい、できる限り早く全体に渡るマッチを終わらせてしまうからです。 RE全体として欲張りにすることで欲しいものが得られます。

SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
Result: {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は、継続して、文字列の先頭と末尾のみにマッチします。

部分的に改行を区別するマッチが指定されると、.とブラケット式は改行を区別するマッチを行うようになりますが、^と$は変更されません。

部分的に改行を区別する逆マッチが指定されると、^と$は改行を区別するマッチを行うようになりますが、.とブラケット式は変更されません。 これはあまり有用ではありません。対称性のために提供されています。

本実装ではREの長さに関する制限はありません。 しかし、移植性を高めたいプログラムでは、256バイトを超えるREを使用すべきではありません。POSIX互換の実装ではそうしたREでは混乱する可能性があります。

AREの機能のうち、POSIX EREと実質的な非互換性があるのは、\がブラケット式の内側で特殊な意味を失わないという点のみです。 他の全てのARE機能は、POSIX EREでは不正、未定義、未指定な効果となる構文を使用しています。決定子の***構文などはBREおよびEREのPOSIX構文にはありません。

多くのARE拡張はPerlから拝借したものです。 しかし、いくつかは整理され、Perlの拡張のいくつかは存在しません。 注意すべき非互換性には、\b、\B、改行の取り扱いに関する特殊な措置の欠落、改行を区別するマッチに影響する点について補足したブラケット式の追加、括弧と先行・後方検索制約内の後方参照についての制限、最長/最短（最初にマッチするではなく）マッチのセマンティクスがあります。

PostgreSQLリリース7.4より前で認知された、AREとERE構文間で大きな非互換が2つあります。

BREはEREといくつかの面において異なります。 BREにおいては、|、+、?は普通の文字であり、それらの機能と等価なものはありません。 バウンドの区切りは\{と\}であり、{と}自身は普通の文字です。 副式を入れ子にするための括弧は\(と\)であり、(と)自身は普通の文字です。 ^は、REの先頭にある場合や括弧内の副式の先頭の場合を除き、普通の文字です。 $は、REの末尾にある場合や括弧内の副式の末尾の場合を除き、普通の文字です。 また、*はREの先頭にある場合や括弧内の副式の先頭にある場合には普通の文字になります（その前に^が付いている可能性もあります）。 最後に、1桁の後方参照を使用することができ、また、BREにおいては、\<と\>はそれぞれ[[:<:]]と[[:>:]]と同義です。

SQL:2008以降、SQL標準にはXQuery正規表現標準によるパターンマッチングを行うLIKE_REGEX演算子が含まれています。 PostgreSQLは今の所この演算子を実装していませんが、regexp_match()を使ってよく似た振る舞いを得ることができます。 XQueryの正規表現は上で述べたARE構文に非常に近いからです。

既存のPOSIXベースの正規表現機能とXQueryの正規表現の主な違いには以下のものが含まれます。