SELECT

FROM 句

FROM 句は一つ以上のソーステーブルを SELECT に指定します。 もし複数のソースが指定されると、結果は概念的に全てのソースの 全ての行の直積になります。しかし通常は制約条件は直積の小さな サブセットを制限するために追加されます。

FROM アイテムが単純なテーブル名の場合、それは暗黙的にそのテーブル のサブテーブル(継承する子)からの行も含みます。 ONLY はそのテーブルのサブテーブルからの 行を抑圧します。Postgres 7.1 以前 ではこれはデフォルトの結果で、サブテーブルの追加は テーブル名に * を付けて行なわれていました。 この古い方法はコマンド SET SQL_Inheritance TO OFF; で使うことができます。

FROM アイテムはカッコで囲まれたサブセレクト(別名句がサブセレクト には必要なことに注意して下さい。)であることもあります。 これは単一の問い合わせの複数レベルのグループ分け、集約、若しくは ソートをする唯一の方法なので、非常に便利な機能です。

最後に、FROM アイテムは二つのより単純な FROM アイテムを組み合われる JOIN 句であることもあります。(ネストの順番を決める必要がある場合 カッコを使います。)

CROSS JOIN もしくは INNER JOIN は単純な直積で、FROM の 最上レベルにその二つのアイテムをリストするのと同じものです。 CROSS JOIN は INNER JOIN ON (TRUE) と等しく、制約ではどの 行も削除されません。これらの結合型は記述上の便宜のためだけで あり、これらは何もしないので単純な FROM と WHERE は 使えません。

LEFT OUTER JOIN は条件にあう直積の全ての行(つまり、その ON 条件を渡す全ての組み合わされた行)、そして ON 条件を渡す右側 の列を持たない左側のテーブルの各々の行のコピーを返します。 この左側の列は右側の列に NULL を挿入することで結合された テーブルの完全な幅まだ拡張されます。どの行が当てはまるものを 持っているか決める間、JOIN 自身の ON か USING 条件のみが 考慮されることに注意してください。他の ON か WHERE 条件 は後で適用されます。

逆に、RIGHT OUTER JOIN は全ての結合された行と、それぞれの 当てはまるものがなかった右側の行(左側は null で拡張されて います)に一行ずつを返します。 左と右の入力を入れ換えることで LEFT OUTER JOIN に変換 することもできるため、これはただの記述上の便宜でしかありません。

FULL OUTER JOIN は全ての結合された行と、当てはまるものが なかった左側の行(右側が null で拡張されている)と、 あてはまるものがなかった右側の行(左側が null で拡張されている) を返します。

CROSS JOIN を除く全ての JOIN 型では、 ON join_condition, USING ( join_column_list ), もしくは NATURAL のどれかを正確に書かなければいけません。ON は もっとも一般的な場合です。結合されるべき二つのテーブル に関連するどのような制約式でも書くことができます。USING 列リスト ( a, b, ... ) は ON 条件 left_table.a = right_table.a AND left_table.b = right_table.b ... の簡略バージョンです。更に USING は、JOIN 出力に含まれる それぞれのペアの同等のカラムのうちの両方ではなく一つだけが 含まれることを意味します。NATURAL はテーブルのなかの似たような 名前を持つ全ての列を挙げる USING リストの簡略バージョンです。

WHERE 句

オプションの WHERE 条件は一般的な形式を持っています。

WHERE boolean_expr
    

     expr cond_op expr
    

     log_op expr
    

GROUP BY 句

GROUP BY はこの句のアプリケーションから作られるグループ化 されたテーブルを指定します。

GROUP BY expression [, ...]
    

GROUP BY は、グループ化された列と同じ値を共有する全ての 選択された行を一つの行に凝縮します。もしあれば、集約関数は それぞれのグループを作る全ての行を渡って計算され、 それぞれのグループに個別の値を作ります(GROUP BY なしでは 集約は全ての選択された行に渡って計算される単一の値を作ります)。 GROUP BY が存在する場合、集約関数内以外では SELECT 出力式が グループ分けされていない列を参照することは妥当ではありません。 なぜならグループ化されていない列には一つ以上の返却可能な 値があるからです。

GROUP BY アイテムは入力カラム名、もしくは出力カラムの順序の番号 の名前(SELECT 式)、もしくは入力列の値に形成される任意の式 が可能です。不明瞭な場合は、GROUP BY 名は出力列名ではなく 入力列名として解釈されます。

HAVING 句

オプションである、HAVING 条件は一般的に次の形式です。

HAVING boolean_expr
    

HAVING は boolean_expr を満たさないグループの行の削除によって発生した グループ化されたテーブルを指定します。 HAVING は WHERE とは違います。WHERE は個別の行を GROUP BY のアプリケーションの前に濾過しますが、HAVING は GROUP BY によって作られるグループ行を濾過します。

boolean_expr で参照される各列は、参照が集約関数内で現れない限り 明瞭にグループ化する列を参照します。

ORDER BY 句

ORDER BY expression [ ASC | DESC | USING operator ] [, ...]
    

ORDER BY アイテムは名前、もしくは出力列(SELECT 式) の順序の番号、もしくは入力列の値から形成される任意の 式を指定することができます。不明瞭な場合は、ORDER BY の 名前は出力列名として解釈されます。

順序の番号は、結果の列の(左から右への)順番の一を参照 します。この機能は正しい名前を持たない列に基づいた順番 を定義することを可能にします。これは完全に必要なことはありません。 なぜなら AS 句を使って結果の列に名前を与えることはいつでも 可能だからです。例えば下記のようになります。

SELECT title, date_prod + 1 AS newlen FROM films ORDER BY newlen;
    

SELECT の結果リストに現れないフィールドを含む 任意の式(SQL92 の拡張)を ORDER BY することも可能です。 したがって下記の文は正当です。

SELECT name FROM distributors ORDER BY code;
    

もし ORDER BY アイテムが結果の列名と入力列名の両方に 当てはまる単純な名前だった場合、ORDER BY はそれを結果 列名として解釈します。これは GROUP BY が同じ状況で行なう 選択の反対です。この不一致は標準 SQL92 からくるものです。

オプションとして、ORDER BY 句の各カラム名の後にキーワード DESC （逆方向）もしくは ASC（順方向）を付けることができます。指定が なければ、デフォルトとして ASC がついているものとします。 代わりに特定の順番演算子の名前を指定することもできます。 ASC は USING < と等しく、DESC は USING > と等しいです。

UNION 句

table_query UNION [ ALL ] table_query
    [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
    

UNION 演算子は、関連する問い合わせが返す行の集合(set union) を計算します。UNION の直接の演算項目を表す二つの SELECT は 同じ数の列を作らなければならず、対応する列は互換性のある データ型でなければなりません。

UNION の結果は ALL オプションが指定されない限りどのような 複写行も含みません。ALl は複写の削除を防ぎます。

同じ SELECT 文にある複数の UNION 演算子は、 カッコで別の順が示されない限り左から右に評価されます。

現在では、FOR UPDATE は UNION の結果もしくは UNION の入力値のどちらにも指定することができません。

INTERSECT 句

table_query INTERSECT [ ALL ] table_query
    [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
    

INTERSECT は UNION と似ていますが、どちらかに現れる行ではなく 両方の問い合わせ出力に現れる行のみを作るという点が違います。

INTERSECT の結果は ALL オプションが指定されない限り どのような複写行も含みません。ALL では、 L に m の複写 を持ち、R に n の複写を持つ行は min(m,n) 回現れます。

同じ SELECT 文の中の複数の INTERSECT 演算子は、カッコで 別の指定がない限り左から右に評価されます。INTERSECT は UNION より更に固く結びつけます。つまり A UNION B INTERSECT C はカッコで別の指定がない限り A UNION (B INTERSECT C) として読まれます。

EXCEPT 句

table_query EXCEPT [ ALL ] table_query
    [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
    

EXCEPT は UNION と似ていますが、右問い合わせの出力ではなく 左問い合わせの出力に現れる行を作るという点で違います。

EXCEPT の結果は ALL オプションが指定されない限りどのような 複写行も含みません。ALL では、L に m の複写を持ち R に n の複写を持つ行は max(m-n,0) 回現れます。

同じ SELECT 文の中の複数の EXCEPT 演算項目は、カッコが それ以外を指定しない限り左から右に評価されます。EXCEPT は UNION と同じレベルで結びつけられます。

LIMIT 句

    LIMIT { count | ALL } [ { OFFSET | , } start ]
    OFFSET start
    

LIMIT は残りの問い合わせから発生する行の一部のみを取りだす ことを可能にします。もし制限数が与えられると、それ以上の 行は返されません。もしオフセットが与えられると、返す行が 始まる前にそれだけの行がとばされます。

LIMIT を使う時は、結果の行を一意な順番に強制する ORDER BY 句を使うのが良い考えです。そうしないと、 問い合わせの行の予測不可能なサブセットを得ることになります。 10 から 20 行目までを出そうとしているかもしれませんが、 どの順番の 10 から 20 行目までなのでしょうか? ORDER BY を指定しない限りどの順番だかわからないのです。

Postgres 7.0 からは、問い合わせ オプティマイザは問い合わせプランを作成する時に LIMIT を 考慮しますので、LIMIT と OFFSET に何を与えるかによって (異なる行の順番を生む)異なったプランを得ることになるでしょう。 したがって、問い合わせの、異なるサブセットを選択するために 異なる LIMIT/OFFSET の値を使うと、 ORDER BY で予測可能な結果を強制しない限り、 矛盾した結果を返します。これはバグでは ありません。これは SQL が ORDER BY で順番を制御しない限り 問い合わせの結果を特定の順番で返すことを約束しないという 事実の本質的な結果なのです。

拡張

Postgres は問い合わせで FROM 句を省略することを可能にします。 この機能はもとの PostQuel 問い合わせ言語から保持されました。 単純な定数式の結果を計算するまっすぐな使用法があります。

SELECT 2+2;

 ?column?
----------
        4
  

SELECT distributors.* WHERE name = 'Westward';

 did | name
-----+----------
 108 | Westward
  

SELECT distributors.* FROM distributors d;
  

SELECT d.* FROM distributors d;
  

SELECT distributors.* FROM distributors d, distributors distributors;
  

SQL92

 
table_query UNION [ALL]
    [CORRESPONDING [BY (column [,...])]]
    table_query