SELECT, TABLE, WITH — テーブルもしくはビューから行を検索する
[ WITH [ RECURSIVE ]with_query
[, ...] ] SELECT [ ALL | DISTINCT [ ON (expression
[, ...] ) ] ] [ * |expression
[ [ AS ]output_name
] [, ...] ] [ FROMfrom_item
[, ...] ] [ WHEREcondition
] [ GROUP BYgrouping_element
[, ...] ] [ HAVINGcondition
] [ WINDOWwindow_name
AS (window_definition
) [, ...] ] [ { UNION | INTERSECT | EXCEPT } [ ALL | DISTINCT ]select
] [ ORDER BYexpression
[ ASC | DESC | USINGoperator
] [ NULLS { FIRST | LAST } ] [, ...] ] [ LIMIT {count
| ALL } ] [ OFFSETstart
[ ROW | ROWS ] ] [ FETCH { FIRST | NEXT } [count
] { ROW | ROWS } { ONLY | WITH TIES } ] [ FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE } [ OFtable_name
[, ...] ] [ NOWAIT | SKIP LOCKED ] [...] ] ここでfrom_item
は以下のいずれかです。 [ ONLY ]table_name
[ * ] [ [ AS ]alias
[ (column_alias
[, ...] ) ] ] [ TABLESAMPLEsampling_method
(argument
[, ...] ) [ REPEATABLE (seed
) ] ] [ LATERAL ] (select
) [ AS ]alias
[ (column_alias
[, ...] ) ]with_query_name
[ [ AS ]alias
[ (column_alias
[, ...] ) ] ] [ LATERAL ]function_name
( [argument
[, ...] ] ) [ WITH ORDINALITY ] [ [ AS ]alias
[ (column_alias
[, ...] ) ] ] [ LATERAL ]function_name
( [argument
[, ...] ] ) [ AS ]alias
(column_definition
[, ...] ) [ LATERAL ]function_name
( [argument
[, ...] ] ) AS (column_definition
[, ...] ) [ LATERAL ] ROWS FROM(function_name
( [argument
[, ...] ] ) [ AS (column_definition
[, ...] ) ] [, ...] ) [ WITH ORDINALITY ] [ [ AS ]alias
[ (column_alias
[, ...] ) ] ]from_item
[ NATURAL ]join_type
from_item
[ ONjoin_condition
| USING (join_column
[, ...] ) ] またgrouping_element
は以下のいずれかです。 ( )expression
(expression
[, ...] ) ROLLUP ( {expression
| (expression
[, ...] ) } [, ...] ) CUBE ( {expression
| (expression
[, ...] ) } [, ...] ) GROUPING SETS (grouping_element
[, ...] ) またwith_query
は以下の通りです。with_query_name
[ (column_name
[, ...] ) ] AS [ [ NOT ] MATERIALIZED ] (select
|values
|insert
|update
|delete
) TABLE [ ONLY ]table_name
[ * ]
SELECT
は0個以上のテーブルから行を返します。
SELECT
の一般的な処理は以下の通りです。
WITH
リスト内のすべての問い合わせが計算されます。
これらは実質的には、FROM
リスト内から参照可能な一時テーブルとして提供されます。
NOT MATERIALIZED
が指定された場合を除き、FROM
内で2回以上参照されるWITH
問い合わせは一度のみ計算されます。
(後述のWITH Clauseを参照してください。)
FROM
リストにある全要素が計算されます
(FROM
リストの要素は実テーブルか仮想テーブルのいずれかです)。
FROM
リストに複数の要素が指定された場合、それらはクロス結合されます
(後述のFROM Clauseを参照してください)。
WHERE
句が指定された場合、条件を満たさない行は全て出力から取り除かれます
(後述のWHERE Clauseを参照してください)。
GROUP BY
句が指定された場合、および集約関数の呼び出しがある場合は、1つまたは複数の値が条件に合う行ごとにグループに組み合わせて出力され、また集約関数の結果が計算されます。
HAVING
句が指定された場合、指定した条件を満たさないグループは取り除かれます
(後述のGROUP BY ClauseとHAVING Clauseを参照してください)。
実際には、選択された各行または行グループに対して、SELECT
の出力式を使用して計算した結果の行が出力されます
(後述のSELECT Listを参照してください)。
SELECT DISTINCT
は結果から重複行を取り除きます。
SELECT DISTINCT ON
は指定した全ての式に一致する行を取り除きます。
SELECT ALL
では、重複行も含め、全ての候補行を返します(これがデフォルトです。
詳しくは、後述のDISTINCT Clauseを参照してください)。
UNION
、INTERSECT
、EXCEPT
演算子を使用すると、複数のSELECT
文の出力を1つの結果集合にまとめることができます。
UNION
演算子は、両方の結果集合に存在する行と、片方の結果集合に存在する行を全て返します。
INTERSECT
演算子は、両方の結果集合に存在する行を返します。
EXCEPT
演算子は、最初の結果集合にあり、2番目の結果集合にない行を返します。
ALL
が指定されない限り、いずれの場合も、重複する行は取り除かれます。
無意味なDISTINCT
という単語を付けて、明示的に重複行を除去することを指定することができます。
SELECT
自体はALL
がデフォルトですが、この場合はDISTINCT
がデフォルトの動作であることに注意してください。
(後述のUNION Clause、INTERSECT Clause、EXCEPT Clauseを参照してください。)
ORDER BY
句が指定された場合、返される行は指定した順番でソートされます。
ORDER BY
が指定されない場合は、システムが計算過程で見つけた順番で行が返されます
(後述のORDER BY Clauseを参照してください)。
LIMIT
(またはFETCH FIRST
)あるいはOFFSET
句が指定された場合、SELECT
文は結果行の一部分のみを返します
(詳しくは、後述のLIMIT Clauseを参照してください)。
FOR UPDATE
、FOR NO KEY UPDATE
、FOR SHARE
またはFOR KEY SHARE
句を指定すると、SELECT
文は引き続き行われる更新に備えて選択行をロックします
(詳しくは、後述のThe Locking Clauseを参照してください)。
SELECT
コマンド内で使われる列それぞれに対するSELECT
権限が必要です。
FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
またはFOR KEY SHARE
を使用するためには、さらに、(選択された各テーブルで少なくとも1列に対する)UPDATE
権限が必要です。
WITH
句
WITH
句により主問い合わせ内で名前により参照可能な、1つ以上の副問い合わせを指定することができます。
副問い合わせは実質的に主問い合わせの間の一時的なテーブルかビューのように動作します。
各副問い合わせはSELECT
、TABLE
、VALUES
、INSERT
、UPDATE
、DELETE
にすることができます。
WITH
内でデータ変更文(INSERT
、UPDATE
、DELETE
)を記述する場合は、RETURNING
句を含めるのが普通です。
主問い合わせで読み取られる一時テーブルを形成するのは、RETURNING
の出力であり、文が変更する背後のテーブルではありません。
RETURNING
を省いても文は実行されますが、出力を生成しませんので、主問い合わせでテーブルとして参照することができません。
(スキーマ修飾がない)名前を各WITH
問い合わせで指定しなければなりません。
列名のリストをオプションで指定することもできます。
これを省略すると、列名は副問い合わせから推定されます。
RECURSIVE
が指定されると、SELECT
副問い合わせは自身で名前により参照することができます。
こうした副問い合わせは以下のような形式でなければなりません。
non_recursive_term
UNION [ ALL | DISTINCT ]recursive_term
ここで再帰的な自己参照はUNION
の右辺に現れなければなりません。
問い合わせ当たり1つの再帰的な自己参照のみが許されます。
再帰的なデータ変更文はサポートされていませんが、データ変更文で再帰的なSELECT
の結果を使用することができます。
例は7.8を参照してください。
RECURSIVE
には他にも、WITH
問い合わせが順序通りでなくても構わないという効果があります。
つまり、問い合わせはリストの後にある別のものを参照することができます。
(しかし巡回する参照や相互的な参照は実装されていません。)
RECURSIVE
がないと、WITH
問い合わせは主問い合わせが共通するWITH
問い合わせのうち、WITH
リストの前方にあるもののみを参照することができます。
WITH
句に複数の問い合わせがある場合、RECURSIVE
はWITH
の直後に一度だけ書くべきです。
再帰や前方参照を使わない問い合わせには効果はないですが、WITH
句内の問い合わせすべてに適用されます。
主問い合わせとWITH
問い合わせは(理論的には)同時に実行されます。
このことは、WITH
中のデータ更新文の効果は、RETURNING
出力の読み込みを行ったことによるものを除き、問い合わせ中の他の部分から見えないことを意味します。
2つのそうしたデータ更新文が同じ行を更新しようとした時の結果は不定です。
WITH
問い合わせの重要な特性は、これらを主問い合わせが複数回参照していたとしても、主問い合わせの実行当たり通常一度のみ評価される点です。
特にデータ変更文は、主問い合わせがその出力のすべてまたは一部を読み取るかに関係なく、本当に一度のみ実行されることが保証されています。
しかし、WITH
問い合わせにNOT MATERIALIZED
と印を付けることにより、この保証を取り除くことができます。
その場合、WITH
問い合わせは、主問い合わせのFROM
句中の単純な副SELECT
であるかのように可能な限り主問い合わせ中に畳み込むことができます。
この結果、主問い合わせがWITH
問い合わせを複数回参照している場合には複数回の計算が行われます。
しかし、そこで使用される問い合わせがWITH
問い合わせ全体の出力のうちの数行しか必要としないなら、NOT MATERIALIZED
は問い合わせを連携して最適化することができるので、全体のコストの節約ができます。
再帰問い合わせあるいは副作用のある問い合わせ(すなわち揮発性の関数を含まない単純SELECT
ではないもの)にNOT MATERIALIZED
を適用しても無視されます。
デフォルトでは、主問い合わせ中のFROM
句で正確に一度だけ使われているなら、副作用のないWITH
問い合わせは主問い合わせに畳み込まれます。
これにより意味論的に不可視の二つの問い合わせレベルが共同して最適化されることを可能にします。
しかし、WITH
問い合わせにMATERIALIZED
と印を付けることにより、そうした畳込みを防ぐことができます。
たとえば、プランナが悪いプランを選択するのを防ぐために最適化障壁としてWITH
問い合わせを使っている場合にこれは有用です。
PostgreSQLバージョン12よりも前ではそうした畳込みは決して行われていなかったので、古いバージョン用に書かれた問い合わせはWITH
が最適化障壁として働くことに依存しているかもしれません。
追加情報については7.8を参照してください。
FROM
句
FROM
句にはSELECT
の対象となるソーステーブルを1つ以上指定します。
複数のソースが指定された場合、結果は全てのソースの直積(クロス結合)となります。
しかし、通常は(WHERE
を介して)制約条件を付けて、直積のごく一部を返すように結果行を限定します。
FROM
句には以下の要素を指定できます。
table_name
既存のテーブルもしくはビューの名前です(スキーマ修飾名も可)。
テーブル名の前にONLY
が指定された場合、そのテーブルのみがスキャンされます。
ONLY
が指定されない場合、テーブルと(もしあれば)それを継承する全てのテーブルがスキャンされます。
省略することもできますが、テーブル名の後に*
を指定することで、明示的に継承するテーブルも含まれることを示すことができます。
alias
別名を含むFROM
項目の代替名です。
別名は、指定を簡潔にするため、もしくは、自己結合(同じテーブルを複数回スキャンする結合)の曖昧さをなくすために使われます。
別名が指定されている場合は、その別名によって実際のテーブル名または関数名が完全に隠されます。
例えば、FROM foo AS f
と指定されている場合、SELECT
文の以降の部分ではこのFROM
項目をfoo
ではなくf
として参照する必要があります。
テーブルの別名があれば、そのテーブルの複数の列の名前を置き換える列の別名リストを記述することができます。
TABLESAMPLE sampling_method
( argument
[, ...] ) [ REPEATABLE ( seed
) ]
table_name
の後のTABLESAMPLE
句は、そのテーブルの行の部分集合を取り出すときに、指定したsampling_method
を使うべきであることを示唆します。
このサンプリングはWHERE
など他のすべてのフィルタの適用に先立って行われます。
PostgreSQLの標準ディストリビューションには、BERNOULLI
とSYSTEM
の2つのサンプリングメソッドが含まれています。
他のサンプリングメソッドも拡張(extension)によりデータベースにインストールすることができます。
サンプリングメソッドBERNOULLI
とSYSTEM
はいずれも1つだけargument
を取り、これはテーブルからサンプリングする割合で0から100までのパーセントで表現されます。
この引数はreal
型の値を取る任意の式にできます。
(他のサンプリングメソッドは、複数の、あるいは異なる引数を受け取るかもしれません。)
これら2つの方法はいずれも、テーブルのうち指定された割合に近い行数を含む、ランダムに選択されたサンプルテーブルを返します。
BERNOULLI
では、テーブル全体を走査し、個々の行を別々に、指定された確率に従って、選択あるいは無視します。
SYSTEM
ではブロックレベルのサンプリングを行います。
各ブロックは指定された確率で選択され、選択されたブロック内のすべての行が返されます。
サンプリングに小さな割合が指定された場合、SYSTEM
はBERNOULLI
よりもかなり高速ですが、クラスタリング効果により、BERNOULLI
に比べてランダムでないサンプルを返すかもしれません。
オプションのREPEATABLE
句では、サンプリングメソッドで乱数を生成するためのseed
の数あるいは式を指定します。
シード値はNULL以外の任意の浮動点小数値とすることができます。
シードとargument
の値が同じ2つの問い合わせは、その間にテーブルに変更がなければ、同じサンプルテーブルを返します。
しかし、シードの値が異なれば、通常は異なるサンプルが生成されます。
REPEATABLE
が指定されていなければ、システムが生成したシードに基づいて、問い合わせ毎に新しくランダムなサンプルが生成されます。
一部のアドオンのサンプリングメソッドではREPEATABLE
が利用できず、使用の度に常に新しいサンプルを生成することに注意してください。
select
FROM
句では、副SELECT
を使うことができます。
SELECT
コマンドの実行中、副SELECT
の出力は一時テーブルであるかのように動作します。
副SELECT
は括弧で囲まれなければなりません。また、必ず別名を与えなければなりません。
VALUESコマンドをここで使用することもできます。
with_query_name
WITH
問い合わせは、問い合わせの名前があたかもテーブル名であるかのように、名前を記述することで参照されます。
(実際にはWITH
問い合わせは主問い合わせの対象とするテーブルと同じ名前の実テーブルを隠蔽します。
必要ならばテーブル名をスキーマ修飾することで同じ名前の実テーブルを参照することができます。)
テーブルと同様の方法で別名を提供することができます。
function_name
FROM
句では、関数呼び出しを使用することができます
(これは特に関数が結果セットを返す場合に有用ですが、任意の関数を使用することもできます)。
SELECT
コマンドの実行中は、この関数の結果は一時テーブルであるかのように動作します。
関数呼び出しにWITH ORDINALITY
句を追加した時は、すべての関数の出力列の後に各行の番号の列が追加されます。
テーブルに対するのと同じように、別名を使用することができます。
別名が記述されていれば、列の別名リストを記述して、関数の複合型の戻り値の1つ以上の、ORDINALITY
がある場合はそれが追加する列を含め、属性に対する代替名を提供することもできます。
複数の関数呼び出しをROWS FROM( ... )
で括ることにより、1つのFROM
句の項目にまとめることができます。
このような項目の出力は各関数の最初の行を結合した項目、次いで各関数の2番目の行、といった具合になります。
一部の関数が他の関数より少ない行数を出力した場合は、存在しないデータについてNULL値が代用され、戻される行数はいつでも最大の行数を返した関数と同じになります。
関数がrecord
データ型を返すと定義されている場合は、別名すなわちAS
キーワードと、それに続く(
という形式の列定義リストが必要です。
列定義リストは、関数によって返される実際の列の数およびデータ型に一致していなければなりません。
column_name
data_type
[, ... ])
ROWS FROM( ... )
の構文を使う時、関数の1つが列定義のリストを必要としている場合は、ROWS FROM( ... )
内の関数呼び出しの後に列定義のリストを置くのが望ましいです。
関数が1つだけで、WITH ORDINALITY
句がない場合に限り、列定義のリストをROWS FROM( ... )
の後に置くことができます。
ORDINALITY
を列定義のリストと一緒に使うには、ROWS FROM( ... )
構文を使い、列定義のリストをROWS FROM( ... )
の内側に置かなければなりません。
join_type
以下のいずれかです。
[ INNER ] JOIN
LEFT [ OUTER ] JOIN
RIGHT [ OUTER ] JOIN
FULL [ OUTER ] JOIN
CROSS JOIN
INNER
およびOUTER
結合型では、結合条件、すなわち、NATURAL
, ON
、join_condition
USING (
のいずれか1つのみを指定する必要があります。
それぞれの意味は後述します。
join_column
[, ...])CROSS JOIN
では、これらの句を記述しなくても構いません。
JOIN
句は、2つのFROM
項目を結び付けます。
便宜上「テーブル」と呼びますが、実際には任意の種類のFROM
項目とすることができます。
入れ子の順番を決めるために、必要ならば括弧を使用してください。
括弧がないと、JOIN
は左から右へ入れ子にします。
どのような場合でもJOIN
は、カンマで分けられたFROM
項目よりも強い結び付きを持ちます。
CROSS JOIN
とINNER JOIN
は直積を1つ生成します。これは、FROM
の最上位で2つのテーブルを結合した結果と同一です。
しかし、(指定すれば)結合条件によって制限をかけることができます。
CROSS JOIN
はINNER JOIN ON (TRUE)
と等価であり、条件によって削除される行はありません。
これらの結合型は記述上の便宜のためだけに用意されています。
なぜなら、通常のFROM
とWHERE
でできないことは何もしないからです。
LEFT OUTER JOIN
は、条件に合う直積の全ての行(つまり、その結合条件を満たす全ての組み合わせ)に加え、左側テーブルの中で、右側テーブルには結合条件を満たす行が存在しなかった行のコピーも返します。
この左側テーブルの行を結合結果のテーブルの幅に拡張するために、右側テーブルが入る列にはNULL値が挿入されます。
マッチする行を決める時は、JOIN
句自身の条件のみが考慮されることに注意してください。
外部結合条件は後で適用されます。
逆に、RIGHT OUTER JOIN
は、全ての結合行と、左側テーブルに当てはまるものがなかった右側の行(左側はNULLで拡張されています)の1行ずつを返します。
左右のテーブルを入れ替えればLEFT OUTER JOIN
に変換できるので、RIGHT OUTER JOIN
は記述上の便宜を図るため用意されているに過ぎません。
FULL OUTER JOIN
は、全ての結合行に加え、一致しなかった左側の行(右側はNULLで拡張)、一致しなかった右側の行(左側はNULLで拡張)を全て返します。
ON join_condition
join_condition
は、結合においてどの行が一致するかを指定する、boolean
型の値を返す式です(WHERE
句に類似しています)。
USING ( join_column
[, ...] )
USING ( a, b, ... )
という形式の句はON left_table.a = right_table.a AND left_table.b = right_table.b ...
の省略形です。
またUSING
は等価な列の両方ではなく片方のみが結合の出力に含まれることを意味します。
NATURAL
NATURAL
は、2つのテーブル内の同じ名前を持つ列を全て指定したUSING
リストの省略形です。
共通の列名がない場合、NATURAL
はON TRUE
と同等になります。
LATERAL
LATERAL
キーワードを副SELECT
のFROM
項目の前に付けることができます。
これにより、副SELECT
がFROM
リストの中で前に現れるFROM
項目の列を参照することができます。
(LATERAL
がないと、副SELECT
それぞれが個別に評価され、他のFROM
項目とのクロス参照を行うことができません。)
LATERAL
を関数を呼び出すFROM
の前に付けることもできます。
しかしこの場合、無意味な単語になります。
関数式はどのような場合でもより前のFROM
項目を参照することができるからです。
LATERAL
項目はFROM
の最上位レベルやJOIN
ツリー内に記述することができます。
後者の場合、JOIN
の右辺にあれば、左辺にある任意の項目を参照することができます。
FROM
項目がLATERAL
クロス参照を含む場合、評価は次のように行われます。
クロス参照される列を提供するFROM
項目の各行、または、その列を提供する複数のFROM
項目の行集合に対して、
LATERAL
項目は列の行または行集合を使用して評価されます。
結果となる行は、計算された行と通常通り結合されます。
これが各行または列ソーステーブルからの行集合に対して繰り返されます。
列ソーステーブルはLATERAL
項目とINNER
またはLEFT
結合されていなければなりません。
さもないと、
LATERAL
項目において各行集合を計算するための行集合が完全に定義することができません。
したがって
という式は構文としては有効ですが、実際にはX
RIGHT JOIN LATERAL Y
Y
ではX
を参照することができません。
WHERE
句
WHERE
句の一般的な構文は以下の通りです(この句は省略可能です)。
WHERE condition
condition
は、評価の結果としてboolean
型を返す任意の式です。
この条件を満たさない行は全て出力から取り除かれます。
全ての変数に実際の行の値を代入して、式が真を返す場合、その行は条件を満たすとみなされます。
GROUP BY
句
GROUP BY
句の一般的な構文は以下の通りです(この句は省略可能です)。
GROUP BY grouping_element
[, ...]
GROUP BY
は、グループ化のために与えられた式を評価し、結果が同じ値になった行を1つの行にまとめる機能を持ちます。
grouping_element
の内側で使われるexpression
には、入力列の名前、出力列(SELECT
リスト項目)の名前/序数、あるいは入力列の値から計算される任意の式を取ることができます。
判断がつかない時は、GROUP BY
の名前は出力列名ではなく入力列名として解釈されます。
グループ化の要素としてGROUPING SETS
、ROLLUP
、CUBE
のいずれかが指定されている場合、GROUP BY
句は全体でいくつかの独立したグループ化セット
を定義します。
この効果は、個々のグループ化セットをGROUP BY
句で定義する副問い合わせをUNION ALL
するのと同等です。
グループ化セットの処理の詳細については、7.2.4を参照してください。
集約関数が使用された場合、各グループ内の全ての行を対象に計算が行われ、グループごとに別々の値が生成されます
(集約関数が使われていてGROUP BY
がない場合、その問い合わせは選択された全ての行からなる1つのグループを持つものとして扱われます)。
集約関数の入力となる行の集合は、集約関数の呼び出しにFILTER
句を付けることで、さらに絞り込むことができます。
詳しくは4.2.7を参照してください。
FILTER
句があると、その条件に適合する行だけが集約関数の入力行に取り込まれます。
GROUP BY
が存在する場合、あるいは集約関数が存在する場合、集約関数内部以外で、グループ化されていない列を参照する、あるいはグループ化されていない列がグループ化された列に関数依存するSELECT
リストの式は無効になります。
こうしないとグループ化されていない列について返される値は複数の値になってしまう可能性があるからです。
グループ化された列(またはその部分集合)がグループ化されていない列を含むテーブルの主キーである場合、関数従属性が存在します。
すべての集約関数は、HAVING
句やSELECT
リストのどの「スカラー」式よりも先に評価されることに注意してください。
これは例えば、CASE
式を集約関数の評価をスキップするために使うことはできない、ということを意味します。
4.2.14を参照してください。
現在は、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
をGROUP BY
と合わせて使うことはできません。
HAVING
句
HAVING
句の一般的な構文は以下の通りです(この句は省略可能です)。
HAVING condition
condition
はWHERE
句で指定するものと同じです。
HAVING
は、グループ化された行の中で、条件を満たさない行を取り除く機能を持ちます。
HAVING
とWHERE
は次の点が異なります。
WHERE
が、GROUP BY
の適用前に個々の行に対してフィルタを掛けるのに対し、HAVING
は、GROUP BY
の適用後に生成されたグループ化された行に対してフィルタをかけます。
condition
内で使用する列は、集約関数内で使用される場合とグループ化されない列がグループ化される列に関数依存する場合を除き、グループ化された列を一意に参照するものでなければなりません。
HAVING
句があると、GROUP BY
句がなかったとしても問い合わせはグループ化された問い合わせになります。
GROUP BY
句を持たない問い合わせが集約関数を含む場合と同様です。
選択された行はすべて、1つのグループを形成するものとみなされます。また、SELECT
リストとHAVING
句では、集約関数が出力するテーブル列しか参照することができません。
こうした問い合わせでは、HAVING
が真の場合には単一の行を、真以外の場合は0行を出力します。
現在は、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
をHAVING
と合わせて使うことはできません。
WINDOW
句
WINDOW
句(省略可能)の一般的な構文は以下の通りです。
WINDOWwindow_name
AS (window_definition
) [, ...]
ここでwindow_name
は、OVER
句やこの後のウィンドウ定義で参照することができる名前です。
また、window_definition
は以下の通りです。
[existing_window_name
] [ PARTITION BYexpression
[, ...] ] [ ORDER BYexpression
[ ASC | DESC | USINGoperator
] [ NULLS { FIRST | LAST } ] [, ...] ] [frame_clause
]
existing_window_name
を指定する場合、それはWINDOW
リスト内のそれより前にある項目を参照しなければなりません。
新しいウィンドウはそのPARTITION BY
句をその項目からコピーします。
ORDER BY
句があった場合も同様です。
この場合、新しいウィンドウでは独自のPARTITION BY
句を指定することはできません。
また、コピーされたウィンドウがORDER BY
を持たない場合のみORDER BY
を指定することができます。
新しいウィンドウは常に独自のフレーム句を使用します。
コピーされたウィンドウはフレーム句を指定してはなりません。
PARTITION BY
リストの要素はGROUP BY
句の要素とほとんど同じように解釈されます。
ただし、こちらは常に単純な式であり、出力列の名前や番号ではないことが異なります。
他にも違いがあり、これらの式は、通常のGROUP BY
句では許されない、集約関数を含めることができるという点です。
グループ化および集約処理の後にウィンドウ処理が動作するため、これらでは許されています。
同様に、ORDER BY
リストの要素は文レベルのORDER BY
句の要素とほとんど同じように解釈されます。
ただし、この式は常に単純な式であり、出力列の名前や番号ではないことが異なります。
frame_clause
を指定すると、(すべてではありませんが)フレームに依存するウィンドウ関数用のウィンドウフレームを定義できます。
ウィンドウフレームは、問い合わせの各行(現在の行と呼ばれます)に関連する行の集合です。
frame_clause
は以下のいずれかを取ることができます。
{ RANGE | ROWS | GROUPS }frame_start
[frame_exclusion
] { RANGE | ROWS | GROUPS } BETWEENframe_start
ANDframe_end
[frame_exclusion
]
ここでframe_start
とframe_end
は以下のいずれかを取ることができます。
UNBOUNDED PRECEDINGoffset
PRECEDING CURRENT ROWoffset
FOLLOWING UNBOUNDED FOLLOWING
また、frame_exclusion
には以下のいずれかを取ることができます。
EXCLUDE CURRENT ROW EXCLUDE GROUP EXCLUDE TIES EXCLUDE NO OTHERS
frame_end
が省略された場合、デフォルトでCURRENT ROW
となります。
frame_start
はUNBOUNDED FOLLOWING
とすることができない、frame_end
はUNBOUNDED PRECEDING
とすることができない、また、frame_start
とframe_end
のオプションの上記リストでframe_end
の選択をframe_start
の選択よりも手前に現れるものにはできない、という制限があります。
例えばRANGE BETWEEN CURRENT ROW AND
は許されません。
offset
PRECEDING
デフォルトのフレーム化オプションはRANGE UNBOUNDED PRECEDING
です。
これはRANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
と同じで、
パーティションの先頭から現在の行の最後のピア(ウィンドウのORDER BY
句が現在行と同等とみなす行、ORDER BY
が無ければ全ての行がピア)までのすべての行をフレームとします。
一般的に、RANGE
やROWS
、GROUPS
のモードにかかわらず、UNBOUNDED PRECEDING
はフレームがパーティションの先頭行から開始することを意味し、同様にUNBOUNDED FOLLOWING
はフレームがパーティションの最終行で終了することを意味します。
ROWS
モードではCURRENT ROW
はフレームが現在の行で開始または終了することを意味しますが、RANGE
あるいはGROUPS
モードではフレームがORDER BY
順序における現在行の最初または最後のピアで開始または終了することを意味します。
offset
PRECEDING
およびoffset
FOLLOWING
オプションの意味はフレームのモードによって異なります。
ROWS
モードでは、offset
はフレームが現在行の何行前または何行後に開始または終了するかを示す整数です。
GROUPS
モードでは、offset
はフレームが現在行のピアグループからピアグループ何個、前または後で開始または終了するかを示す整数です。
ここでピアグループとはウィンドウのORDER BY
句において等価の行のグループです。
RANGE
モードでは、offset
オプションを使うには、ウィンドウ定義に一つだけORDER BY
列があることが必要です。
それで、整列する列の値がoffset
を超えないだけ、現在行の整列する列の値より小さい(PRECEDING
に対して)、あるいは、より大きい(FOLLOWING
に対して)行がフレームに含まれます。
この場合、offset
式のデータ型は整列する列のデータ型によって決まります。
数値の整列する列に対するoffset
は一般的に整列する列と同じ型ですが、日付時刻の整列する列に対してはinterval
になります。
これら全ての場合で、offset
の値は非NULLかつ非負でなければなりません。
また、offset
が単純な定数である必要はありませんが、変数や集約関数、ウィンドウ関数を含めることはできません。
frame_exclusion
オブションは現在行の周辺の行を、フレーム開始とフレーム終了のオプションにより含まれるものであっても、フレームから除外することができます。
EXCLUDE CURRENT ROW
はフレームから現在行を除外します。
EXCLUDE GROUP
はフレームから現在行とその整列ピアを除外します。
EXCLUDE TIES
は現在行自身を除いた現在行のピアをフレームから除外します。
EXCLUDE NO OTHERS
は単に、現在行もそのピアも除外しないというデフォルトの振る舞いを明示的に指定します。
ORDER BY
順序によりその行を一意に順序付けできない場合、ROWS
モードが予期できない結果をもたらす可能性があることに注意して下さい。
RANGE
およびGROUPS
モードは、ORDER BY
順序におけるピアとなる行が同等に扱われる、すなわち、与えられたピアグループの全行がフレームに入るか除外されるように設計されています。
WINDOW
句の目的は、問い合わせのSELECT
リストまたはORDER BY
句に記載されるウィンドウ関数の動作を規定することです。
これらの関数はそのOVER
句において名前でWINDOW
句の項目を参照することができます。
しかしWINDOW
句の項目は他で参照される必要はありません。
問い合わせ内で使用されなかったものは、単に無視されます。
ウィンドウ関数呼び出しはOVER
句でウィンドウ定義を直接規定することができますので、WINDOW
句を全く使わずにウィンドウ関数を使用することができます。
しかしWINDOW
句は、同じウィンドウ定義が複数のウィンドウ関数で必要とされる場合に入力量を省くことができます。
現在は、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
をWINDOW
と合わせて使うことはできません。
SELECT
リスト
SELECT
リスト(SELECT
キーワードとFROM
キーワードの間にあるもの)は、SELECT
文の出力行を形成する式を指定するものです。
この式では、FROM
句で処理後の列を参照することができます(通常は実際に参照します)。
テーブルの場合と同様に、SELECT
の出力列はすべて名前を持ちます。
簡単なSELECT
では、この名前は列に表示用のラベルを付けるために使用されるだけです。
しかしSELECT
が大規模な問い合わせの副問い合わせである場合、大規模な問い合わせ側で副問い合わせで生成された仮想のテーブルの列名としてこの名前が参照されます。
出力列として使用するための名前を指定するためには、列式の後にAS
output_name
と記述してください。
(希望する列名がPostgreSQLのキーワード(付録Cを参照)に一致しない場合にのみAS
を省略することができます。
将来あり得るキーワードの追加に備えるために、常にAS
を記述する、あるいは、出力名を二重引用符で括ることを推奨します。)
列名を指定しない場合、名前はPostgreSQLにより自動的に付けられます。
列式が単純な列参照であれば、つけられる名前はその列の名前と同じものです。
より複雑な場合では、関数名または型名が使用されるかもしれません。さもなければ?column?
のように生成される名前になるかもしれません。
ORDER BY
句とGROUP BY
句内で列の値を参照する時も、出力列名を使用できます。
しかし、WHERE
やHAVING
句では使用できません。これらでは式を書かなければなりません。
リストには、選択された行の全ての列を表す省略形として、式ではなく*
と書くことができます。
また、そのテーブルに由来する列のみを表す省略形として、
と書くこともできます。
このような場合、table_name
.*AS
により新しい名前を指定することはできません。
出力列名はテーブルの列名と同一になります。
標準SQLによれば、出力リスト内の式は、DISTINCT
、ORDER BY
、LIMIT
を適用する前に計算することになっています。
DISTINCT
を使う場合は、これは明らかに必要です。
なぜなら、そうしなければどの値がDISTINCTであるかわからないからです。
しかし、多くの場合、ORDER BY
やLIMIT
の後で出力式を計算する方が便利です。
特に出力式が揮発性(volatile)あるいは高価な式を含んでいる場合はそうです。
この動作により、関数の評価順序はより直感的になり、出力に現れない行については評価されなくなります。
PostgreSQLでは、式がDISTINCT
、ORDER BY
、GROUP BY
の中で参照されていない限り、ソートと制限(limit)の後にそれらの式を実際に評価します。
(この反例として、SELECT f(x) FROM tab ORDER BY 1
では明らかにf(x)
をソートの前に評価しなければなりません。)
集合を返す関数を含む出力式は、ソートの後、制限の前に実際の評価が行われ、これによりLIMIT
が集合を返す関数の出力を制限することになります。
PostgreSQLのバージョン9.6より前では、出力式がソートや制限に対して評価されるタイミングについて何の保証もしていませんでした。 それは選択された問い合わせの計画の形式に依存します。
DISTINCT
句
SELECT DISTINCT
が指定されると、重複する行は全て結果セットから削除されます
(重複するグループの中で1行が保持されます)。
SELECT ALL
はこの反対で、全ての行が保持されます。
デフォルトはこちらです。
SELECT DISTINCT ON (
は指定した式が等しいと評価した各行集合の中で、最初の行のみを保持します。
expression
[, ...] )DISTINCT ON
式は、ORDER BY
(上述)と同じ規則で扱われます。
各集合の「最初の行」は、ORDER BY
を使用して目的の行が確実に最初に現れるようにしない限り予測することはできないことに注意してください。
例えば、次の例は各地点の最新の気象情報を取り出します。
SELECT DISTINCT ON (location) location, time, report FROM weather_reports ORDER BY location, time DESC;
しかしORDER BY
を使用して各地点を時間によって降順にソートしなければ、各地点について得られる情報がいつのものかはわかりません。
DISTINCT ON
に指定する式はORDER BY
の最も左側の式と一致しなければなりません。
ORDER BY
句は、通常、各DISTINCT ON
グループの中での行の優先順位を決定する追加的な式を含みます。
現在は、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
をDISTINCT
と合わせて使うことはできません。
UNION
句
UNION
句の一般的な構文は以下の通りです。
select_statement
UNION [ ALL | DISTINCT ]select_statement
select_statement
には、ORDER BY
、LIMIT
、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
句を持たない任意のSELECT
文が入ります
(ORDER BY
とLIMIT
は、括弧で囲めば副式として付与することができます。
括弧がない場合、これらの句は右側に置かれた入力式ではなく、UNION
の結果に対して適用されてしまいます)。
UNION
演算子は、2つのSELECT
文が返す行の和集合を作成します。
この和集合には、2つのSELECT
文の結果集合のいずれか(または両方)に存在する行が全て含まれています。
UNION
の直接のオペランドとなる2つのSELECT
文が返す列数は、同じでなければなりません。また、対応する列のデータ型には互換性が存在する必要があります。
ALL
オプションが指定されていない限り、UNION
の結果には重複行は含まれません。
ALL
を指定するとこのような重複除去が行われません
(したがって、通常UNION ALL
はUNION
よりかなり高速です。
できればALL
を使用してください)。
重複行を除去するデフォルトの動作を明示的に指定するためにDISTINCT
を記述することができます。
1つのSELECT
文に複数のUNION
演算子がある場合、括弧がない限り、それらは左から右に評価されます。
現時点では、UNION
の結果やUNION
に対する入力に、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
を指定することはできません。
INTERSECT
句
INTERSECT
句の一般的な構文は以下の通りです。
select_statement
INTERSECT [ ALL | DISTINCT ]select_statement
select_statement
には、ORDER BY
、LIMIT
、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
句を持たない、任意のSELECT
文が入ります。
INTERSECT
は、2つのSELECT
文が返す行の積集合を計算します。
この積集合に含まれるのは、2つのSELECT
文の結果集合の両方に存在する行です。
ALL
オプションを指定しない限り、INTERSECT
の結果に重複行は含まれません。
ALL
が指定された場合、左側テーブルにm
個、右側テーブルにn
個の重複がある行は、結果集合ではmin(m
,n
)個出現します。
重複行を除去するデフォルトの動作を明示的に指定するためにDISTINCT
を記述することができます。
1つのSELECT
文に複数のINTERSECT
演算子がある場合、括弧がない限り、それらは左から右に評価されます。
INTERSECT
はUNION
よりも強い結び付きを持ちます。
つまり、A UNION B INTERSECT C
はA UNION (B INTERSECT C)
と解釈されます。
現時点では、INTERSECT
の結果やINTERSECT
に対する入力に、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
またはFOR KEY SHARE
を指定することはできません。
EXCEPT
句
EXCEPT
句の一般的な構文は以下の通りです。
select_statement
EXCEPT [ ALL | DISTINCT ]select_statement
select_statement
には、ORDER BY
、LIMIT
、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
句を持たない、任意のSELECT
文が入ります。
EXCEPT
は、左側のSELECT
文の結果には存在し、右側のSELECT
文の結果には存在しない行の集合を生成します。
ALL
オプションが指定されていない限り、EXCEPT
の結果には重複行は含まれません。
ALL
がある場合、左側テーブルにm
個、右側テーブルにn
個の重複がある行は、結果集合ではmax(m
-n
,0)個出現します。
重複行を除去するデフォルトの動作を明示的に指定するためにDISTINCT
を記述することができます。
1つのSELECT
文に複数のEXCEPT
演算子がある場合、括弧がない限り、それらは左から右に評価されます。
EXCEPT
の結び付きの強さはUNION
と同じです。
現時点では、EXCEPT
の結果やEXCEPT
に対する入力に、FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
またはFOR KEY SHARE
を指定することはできません。
ORDER BY
句
ORDER BY
句の一般的な構文は以下の通りです(この句は省略可能です)。
ORDER BYexpression
[ ASC | DESC | USINGoperator
] [ NULLS { FIRST | LAST } ] [, ...]
ORDER BY
句を使うと、結果行を指定した式(複数可)に従ってソートすることができます。
最も左側の式を使って比較した結果、2つの行が等しいと判断された場合は、1つ右側の式を使って比較します。その結果も等しければ、さらに次の式に進みます。
指定した全ての式で等しいと判断された場合は、実装に依存した順番で返されます。
expression
には、出力列(SELECT
リスト項目)の名前または序数、あるいは入力列値から形成される任意の式を取ることができます。
序数は、出力列の位置(左から右に割り当てられます)を示します。
これを使うと、一意な名前を持たない列の順序を定義することができます。
AS
句を使用すれば出力列に名前を割り当てることができるので、これはどうしても必要な機能というわけではありません。
また、ORDER BY
句には、SELECT
出力リストに出現しない列を含む、任意の式を使用できます。
したがって、以下の文は有効です。
SELECT name FROM distributors ORDER BY code;
ただし、UNION
、INTERSECT
、EXCEPT
の結果にORDER BY
を適用する場合は、式は使用できず、出力列の名前か序数のみを指定できるという制限があります。
ORDER BY
の式として出力列名と入力列名の両方に一致する単なる名前が与えられた場合、ORDER BY
はそれを出力列名として扱います。
これは、同じ状況におけるGROUP BY
の選択とは反対です。
この不整合は、標準SQLとの互換性を保持するために発生しています。
ORDER BY
中の任意の式の後に、キーワードASC
(昇順)、DESC
(降順)を付加することができます(省略可能)。
指定がなければ、デフォルトでASC
があるものとして扱われます。
その他、順序を指定する演算子名をUSING
句に指定する方法もあります。
順序指定演算子は何らかのB-Tree演算子族の小なりまたは大なり演算子でなければなりません。
通常、ASC
はUSING <
と、DESC
はUSING >
と同じです
(ただし、ユーザ定義データ型の作成時には、デフォルトのソート順を定義することができます。また、異なる名前の演算子と対応付けすることもできます)。
NULLS LAST
が指定されると、NULL値はすべての非NULL値の後にソートされます。
NULLS FIRST
が指定されると、NULL値はすべての非NULL値の前にソートされます。
どちらも指定されない場合のデフォルト動作は、明示的あるいは暗黙的なASC
の場合はNULLS LAST
、DESC
が指定された場合はNULLS FIRST
です。
(したがって、デフォルトでは、NULLが非NULLよりも大きい値であるかのように動作します。)
USING
が指定されると、デフォルトのNULLの順序は、演算子が小なり演算子か大なり演算子によって変わります。
順序付けオプションは直前の演算子にのみ適用されます。
たとえば、ORDER BY x, y DESC
はORDER BY x DESC, y DESC
と同一の意味ではありません。
文字型データでは、格納する列に適用された照合順序に従ってソートされます。
これは必要に応じてexpression
内にCOLLATE
句を含めることで上書きできます。
例えばORDER BY mycolumn COLLATE "en_US"
です。
より詳細については4.2.10および23.2を参照してください。
LIMIT
句
LIMIT
句は2つの独立した副句から構成されます。
LIMIT {count
| ALL } OFFSETstart
パラメータcount
には返される行の最大数を、一方、start
には行を返し始める前に飛ばす行数を指定します。
両方とも指定された場合、start
行分が飛ばされ、そこから数えてcount
行が返されます。
count
式がNULLと評価された場合、LIMIT ALL
として、つまり制限無しとして扱われます。
start
がNULLと評価された場合、OFFSET 0
と同様に扱われます。
SQL:2008では同じ結果を実現する異なる構文が導入されました。 PostgreSQLでもサポートしています。 以下の構文です。
OFFSETstart
{ ROW | ROWS } FETCH { FIRST | NEXT } [count
] { ROW | ROWS } { ONLY | WITH TIES }
この構文において、start
またはcount
の値は標準SQLでは、リテラル定数、パラメータもしくは変数名を要求します。
PostgreSQLの拡張では他の表現が許容されていますが、曖昧さを防ぐために通常は括弧で囲まれる必要があるでしょう。
count
をFETCH
句で省略した場合、そのデフォルトは1です。
WITH TIES
オプションは、結果の集合でORDER BY
句に従って最後の場所で同点になる追加の行を返すのに使われます。この場合ORDER BY
は必須です。
ROW
およびROWS
、そしてFIRST
およびNEXT
は意味がない単語で、この句に影響を与えることはありません。
SQL標準ではOFFSET
句は、FETCH
句と同時に使用する場合、これより前に存在しなければなりません。
しかしPostgreSQLは厳密ではなく、どちらが先でも許されます。
LIMIT
を使う時は、結果行を一意な順番に強制するORDER BY
句を使うとよいでしょう。
そうしないと、問い合わせ結果のどの部分が返されるのかがわかりません。
10〜20行目までを出力するとしても、どの順番で並べた時の10〜20行目なのでしょうか。
ORDER BY
を指定しない限り、行が返される順番は不明です。
問い合わせプランナは問い合わせ計画を作成する時にLIMIT
を考慮するので、LIMIT
とOFFSET
の指定によって異なった計画を得ることになるでしょう。計画が異なれば、異なる順番で行が返ります。
したがって、LIMIT
/OFFSET
値の変更によって異なる結果行を選択しようとすると、ORDER BY
で順序を並び替えない限り、矛盾した結果を返すことになります。
これはバグではありません。
「SQLは、ORDER BY
で順序を制御されない限り、問い合わせ結果が返す順序を約束しない」という事実の当然の帰結なのです。
厳密的に部分集合の選択を強制するORDER BY
がなければ、同じLIMIT
問い合わせを繰り返し実行してもテーブル行から異なる部分集合が取り出される可能性すらあります。
繰り返しますが、これは不具合ではありません。
こうした場合に確定した結果は単に保証されていないのです。
FOR UPDATE
、FOR NO KEY UPDATE
、FOR SHARE
およびFOR KEY SHARE
はロック処理句です。
これらはテーブルから行を入手する時にどのようにSELECT
がその行をロックするかに影響します。
ロック処理句の一般的な構文は以下の通りです。
FORlock_strength
[ OFtable_name
[, ...] ] [ NOWAIT | SKIP LOCKED ]
ここでlock_strength
は以下のいずれかを取ることができます。
UPDATE NO KEY UPDATE SHARE KEY SHARE
それぞれの行レベルロックモードについての詳しい説明は13.3.2を参照してください。
他のトランザクションのコミットを待機することなく操作を進めるには、NOWAIT
あるいはSKIP LOCKED
オプションを使用してください。
NOWAIT
では、選択行のロックを即座に獲得できない時、文は待機せずに、エラーを報告します。
SKIP LOCKED
では、即座にロックできない行はすべてスキップされます。
行のロックをスキップすると、一貫性のないデータが見えることになるので、一般的な目的の作業のためには適しませんが、複数の消費者がキューのようなテーブルにアクセスするときのロック競合の回避などに利用できます。
NOWAIT
およびSKIP LOCKED
は行レベルロックにのみに適用される点に注意してください。
つまり、必要なROW SHARE
テーブルレベルロックは通常通りの方法( 第13章を参照)で獲得されます。
もし、テーブルレベルのロックを待機せずに獲得しなければならないのであれば、最初にLOCKのNOWAIT
オプションを使用してください。
ロック処理句内に特定のテーブルが指定されている場合は、そのテーブルの行のみがロックされます。
SELECT
内の他のテーブルは通常通りに読み込まれます。
テーブルリストを持たないロック処理句は、その文で使用されるすべてのテーブルに影響を与えます。
ロック処理句がビューまたは副問い合わせで使用された場合、そのビューや副問い合わせで使用されるすべてのテーブルに影響を与えます。
しかしこれらの句は主問い合わせで参照されるWITH
問い合わせには適用されません。
WITH
問い合わせ内での行ロックを行いたい場合は、WITH
問い合わせ内でロック処理句を指定してください。
異なるロック方式を異なるテーブルに指定する必要があれば、複数のロック処理句を記述することができます。
複数のロック処理句で同一のテーブルを記述した(または暗黙的に影響が与えられた)場合、最も強いものだけが指定されたかのように処理されます。
同様に、あるテーブルに影響を与える句のいずれかでNOWAIT
が指定された場合、そのテーブルはNOWAIT
として処理されます。
それ以外の場合、あるテーブルに影響を与える句のいずれかでSKIP LOCKED
が指定されていれば、そのテーブルはSKIP LOCKED
として処理されます。
ロック処理句は、返される行がテーブルのどの行に対応するのかが明確に識別できない場合には使用することができません。 例えば、集約には使用できません。
ロック処理句がSELECT
問い合わせの最上位レベルに存在する場合、ロック対象行は問い合わせが返す行に正確に一致します。
結合問い合わせ内の場合、ロック対象行は返される結合行に関連する行となります。
さらに、スナップショットを更新した後に問い合わせ条件を満たさなくなった場合は返されなくなりますが、問い合わせのスナップショット時点で問い合わせ条件を満たす行もロックされます。
LIMIT
が使用された場合、制限を満たす行が返されるとロック処理は止まります。
(しかし、OFFSET
により飛ばされた行はロックされることに注意してください。)
同様に、ロック処理句がカーソル問い合わせで使用された場合、カーソルにより実際に取り込んだ行または通り過ぎた行のみがロックされます。
ロック処理句が副SELECT
に存在する場合、ロック対象行は副問い合わせの外側の問い合わせに返される行となります。
外側の問い合わせからの条件が副問い合わせ実行の最適化に使用される可能性がありますので、これには副問い合わせ自体の検査が提示する行より少なくなるかもしれません。
例えば、
SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss WHERE col1 = 5;
は、副問い合わせ内では文字として条件が記載されていなくても、col1 = 5
を持つ行のみがロックされます。
以前のリリースでは、セーブポイント以降に更新されるロックの保持は失敗しました。 例えば以下のコードです。
BEGIN; SELECT * FROM mytable WHERE key = 1 FOR UPDATE; SAVEPOINT s; UPDATE mytable SET ... WHERE key = 1; ROLLBACK TO s;
ROLLBACK TO
後のFOR UPDATE
ロックの保持に失敗します。
これはリリース9.3で修正されました。
ORDER BY
句とロック処理句を使用した、READ COMMITTED
トランザクション分離レベルで実行するSELECT
コマンドでは、順序通りにならない行を返す可能性があります。
ORDER BY
が最初に適用されるためです。
このコマンドは結果をソートしますが、その後、1行または複数の行のロック獲得がブロックされる可能性があります。
このSELECT
のブロックが解除された時点で、順序付け対象の列値の一部が変更されているかもしれません。
これによりこうした行が(元の列値という観点では順序通りではありますが、)順序通りに現れません。
必要に応じて、これは以下のように副問い合わせ内にFOR UPDATE/SHARE
句を記述することで、回避することができます。
SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss ORDER BY column1;
最上位レベルにおけるFOR UPDATE
は実際に返される行のみをロックするのに対して、これは結果としてmytable
のすべての行をロックすることに注意してください。
これは、特にORDER BY
がLIMIT
やその他の制限と組み合わせている場合、性能上大きな違いを生み出す可能性があります。
このため、この技法は、順序付け対象の列に対する同時実行の更新が想定され、かつ、厳密にソートされた結果が要求される場合にのみ推奨されます。
REPEATABLE READ
またはSERIALIZABLE
トランザクション分離レベルでは、('40001'
というSQLSTATE
を持つ)シリアライゼーション失敗が発生します。
このためこれらの分離レベルでは順序通りでない行を受け取る可能性はありません。
TABLE
コマンド
TABLE name
というコマンドは以下と同じです。
SELECT * FROM name
これは、最上位のコマンドとして、あるいは複雑な問い合わせの一部として、入力を省略する構文の一種としても使用することができます。
WITH
、UNION
、INTERSECT
、EXCEPT
、ORDER BY
、LIMIT
、OFFSET
、FETCH
、FOR
のロック句だけをTABLE
と一緒に使うことができます。
WHERE
句およびいかなる形式の集約も使うことはできません。
films
テーブルをdistributors
テーブルと結合します。
SELECT f.title, f.did, d.name, f.date_prod, f.kind FROM distributors d, films f WHERE f.did = d.did title | did | name | date_prod | kind -------------------+-----+--------------+------------+---------- The Third Man | 101 | British Lion | 1949-12-23 | Drama The African Queen | 101 | British Lion | 1951-08-11 | Romantic ...
全ての映画のlen
列を合計しkind
列によって結果をグループ化します。
SELECT kind, sum(len) AS total FROM films GROUP BY kind; kind | total ----------+------- Action | 07:34 Comedy | 02:58 Drama | 14:28 Musical | 06:42 Romantic | 04:38
全ての映画のlen
列を合計しkind
列によって結果をグループ化し、合計が5時間より少ないグループの合計を表示します。
SELECT kind, sum(len) AS total FROM films GROUP BY kind HAVING sum(len) < interval '5 hours'; kind | total ----------+------- Comedy | 02:58 Romantic | 04:38
次に、結果を2番目の列(name
)の内容に基づいてソートする方法を2つ例示します。
SELECT * FROM distributors ORDER BY name; SELECT * FROM distributors ORDER BY 2; did | name -----+------------------ 109 | 20th Century Fox 110 | Bavaria Atelier 101 | British Lion 107 | Columbia 102 | Jean Luc Godard 113 | Luso films 104 | Mosfilm 103 | Paramount 106 | Toho 105 | United Artists 111 | Walt Disney 112 | Warner Bros. 108 | Westward
次の例は、distributors
テーブルとactors
テーブルの和集合を取得する方法を示しています。さらに、両方のテーブルで結果をWという文字で始まる行のみに限定しています。
重複しない行のみが必要なので、ALL
キーワードは省略されています。
distributors: actors: did | name id | name -----+-------------- ----+---------------- 108 | Westward 1 | Woody Allen 111 | Walt Disney 2 | Warren Beatty 112 | Warner Bros. 3 | Walter Matthau ... ... SELECT distributors.name FROM distributors WHERE distributors.name LIKE 'W%' UNION SELECT actors.name FROM actors WHERE actors.name LIKE 'W%'; name ---------------- Walt Disney Walter Matthau Warner Bros. Warren Beatty Westward Woody Allen
次に、FROM
句内での関数の使用方法について、列定義リストがある場合とない場合の両方の例を示します。
CREATE FUNCTION distributors(int) RETURNS SETOF distributors AS $$ SELECT * FROM distributors WHERE did = $1; $$ LANGUAGE SQL; SELECT * FROM distributors(111); did | name -----+------------- 111 | Walt Disney CREATE FUNCTION distributors_2(int) RETURNS SETOF record AS $$ SELECT * FROM distributors WHERE did = $1; $$ LANGUAGE SQL; SELECT * FROM distributors_2(111) AS (f1 int, f2 text); f1 | f2 -----+------------- 111 | Walt Disney
以下は序数列が追加された関数の例です。
SELECT * FROM unnest(ARRAY['a','b','c','d','e','f']) WITH ORDINALITY; unnest | ordinality --------+---------- a | 1 b | 2 c | 3 d | 4 e | 5 f | 6 (6 rows)
以下の例では簡単なWITH
句の使用方法を示します。
WITH t AS ( SELECT random() as x FROM generate_series(1, 3) ) SELECT * FROM t UNION ALL SELECT * FROM t x -------------------- 0.534150459803641 0.520092216785997 0.0735620250925422 0.534150459803641 0.520092216785997 0.0735620250925422
WITH
問い合わせが一度だけ評価されることに注意してください。
このため3つのランダムな値の同じ集合2組を得ることになります。
以下の例ではWITH RECURSIVE
を使用して、直接の部下しか表示しないテーブルから、従業員Maryの(直接または間接的な)部下とその間接度を見つけ出します。
WITH RECURSIVE employee_recursive(distance, employee_name, manager_name) AS ( SELECT 1, employee_name, manager_name FROM employee WHERE manager_name = 'Mary' UNION ALL SELECT er.distance + 1, e.employee_name, e.manager_name FROM employee_recursive er, employee e WHERE er.employee_name = e.manager_name ) SELECT distance, employee_name FROM employee_recursive;
初期条件、続いてUNION
、さらに問い合わせの再帰部分という再帰問い合わせの典型的な構文に注意してください。
問い合わせの再帰部分は最終的にはタプルを返さないことを確実にしてください。
さもないと問い合わせは無限にループします。
(より多くの例については7.8を参照してください。)
以下の例では、manufacturers
テーブルの各行に対して集合を返すget_product_names()
関数を適用するためにLATERAL
を使用します。
SELECT m.name AS mname, pname FROM manufacturers m, LATERAL get_product_names(m.id) pname;
これは内部結合ですので、現時点で製品をまったく持たないメーカは結果に現れません。 こうしたメーカの名前も結果に含めたければ以下のようにします。
SELECT m.name AS mname, pname FROM manufacturers m LEFT JOIN LATERAL get_product_names(m.id) pname ON true;
当然ながら、SELECT
文は標準SQLと互換性があります。
しかし、拡張機能や実現されていない機能もいくつかあります。
FROM
句の省略
PostgreSQLでは、FROM
句を省略することができます。
これによって、以下のように単純な式を計算させることができます。
SELECT 2+2; ?column? ---------- 4
他のSQLデータベースでは、このようなSELECT
を行うためにはダミーの1行テーブルを使わなければならないものもあります。
FROM
句の指定がない場合、問い合わせではデータベーステーブルを参照することができません。
例えば、以下の問い合わせは無効です。
SELECT distributors.* WHERE distributors.name = 'Westward';
PostgreSQLリリース8.1より前まででは、こうした形の問い合わせを受け付け、問い合わせで参照する各テーブルに対する暗黙的な項目を問い合わせのFROM
句に追加していました。
これは許されなくなりました。
SELECT
リスト
SELECT
の後の出力式のリストは空でも良く、このとき列数がゼロの結果テーブルが生成されます。
これは標準SQLでは有効な構文ではありませんが、PostgreSQLは列数がゼロのテーブルを許すので、それと整合性を保つために許しています。
しかし、DISTINCT
を使う時は、空のリストを使うことはできません。
AS
キーワードの省略
標準SQLでは、キーワードAS
(省略可能)は、新しい列名が有効な列名(つまり予約済みのどのキーワードとも異なるもの)である場合は常に、出力列名の前から省くことができます。
PostgreSQLには多少より強い制限があります。
新しい列名が予約済みか否かに関わらず何らかのキーワードに一致する場合はAS
が必要です。
推奨する実践方法は、今後のキーワードの追加と競合する可能性に備え、AS
を使用する、または出力列名を二重引用符で括ることです。
FROM
項目において標準およびPostgreSQLでは、未予約のキーワードである別名の前のAS
を省略することができます。
しかし、構文があいまいになるため、出力名では実践的ではありません。
ONLY
と継承関係
標準SQLでは、SELECT * FROM ONLY (tab1), ONLY (tab2) WHERE ...
のように、ONLY
を記述する時にテーブル名の前後を括弧でくくることを要求します。
PostgreSQLではこの括弧を省略可能であるとみなしています。
PostgreSQLでは最後に*
を付けることで
明示的に子テーブルを含めるというONLY
ではない動作を指定することができます。
標準ではこれを許していません。
(これらの点はONLY
オプションをサポートするすべてのSQLコマンドで同様に適用されます。)
TABLESAMPLE
句の制限
現在のところ、TABLESAMPLE
句は通常のテーブルとマテリアライズドビューでのみ受け付けられます。
SQL標準では、FROM
句の任意の要素について適用可能であるべきとされています。
FROM
内の関数呼び出し
PostgreSQLでは、FROM
リストのメンバとして直接関数呼び出しを記述することができます。
標準SQLではこうした関数呼び出しを副SELECT
内に囲む必要があります。
つまりFROM
はおおよそfunc
(...) alias
FROM LATERAL (SELECT
と同じです。
暗黙的にfunc
(...)) alias
LATERAL
であるとみなされることに注意してください。
標準ではFROM
内のUNNEST()
項目にはLATERAL
構文を必要とするためです。
PostgreSQLではUNNEST()
を他の集合を返す関数と同じものとして扱います。
GROUP BY
とORDER BY
における利用可能な名前空間
標準SQL-92では、ORDER BY
句で使用できるのは、出力列名か序数のみであり、GROUP BY
句で使用できるのは、入力列名からなる式のみです。
PostgreSQLは、これらの句で両方が指定できるように拡張されています
(ただし、不明瞭さがある場合は標準の解釈が使用されます)。
さらに、PostgreSQLではどちらの句にも任意の式を指定できます。
式で使われる名前は、常に出力列名ではなく入力列の名前とみなされることに注意してください。
SQL:1999以降では、SQL-92と完全には上位互換でない、多少異なる定義が採用されています。
しかし、ほとんどの場合、PostgreSQLはSQL:1999と同じ方法でORDER BY
やGROUP BY
を解釈します。
テーブルの主キーがGROUP BY
リストに含まれる場合に限り、PostgreSQLは(GROUP BY
で列を省くことができる)関数従属性を認識します。
標準SQLでは、認識しなければならない追加の条件を規定しています。
LIMIT
およびOFFSET
LIMIT
およびOFFSET
句はPostgreSQL独自の構文ですが、MySQLでも使用されています。
LIMIT Clauseで説明したように、標準SQL:2008にて同じ機能のOFFSET ... FETCH {FIRST|NEXT} ...
が導入されました。
この構文はIBM DB2でも使用されています。
(Oracle用に開発されたアプリケーションでは、これらの句の機能を実装するために自動生成されるrownum
列を含めるという回避策を使用することが多いですが、PostgreSQLでは利用できません。)
FOR NO KEY UPDATE
、FOR UPDATE
、FOR SHARE
、FOR KEY SHARE
FOR UPDATE
は標準SQLに存在しますが、標準では、DECLARE CURSOR
のオプションとしてしか許されていません。
PostgreSQLでは、副SELECT
など任意のSELECT
で許されます。
これは拡張です。
FOR NO KEY UPDATE
、FOR SHARE
、FOR KEY SHARE
の亜種、およびNOWAIT
とSKIP LOCKED
オプションは標準にはありません。
WITH
内のデータ変更文
PostgreSQLではWITH
問い合わせとしてINSERT
、UPDATE
およびDELETE
を使用することができます。
これは標準SQLにはありません。
DISTINCT ON ( ... )
は標準SQLの拡張です。
ROWS FROM( ... )
は標準SQLの拡張です。
WITH
のMATERIALIZED
とNOT MATERIALIZED
オプションはSQL標準の拡張です。