他のバージョンの文書9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

7.3. 選択リスト

前節で示したように、SELECTコマンド中のテーブル式は、テーブルの結合やビュー、行の抽出、グループ化などにより中間の仮想テーブルを作ります。 このテーブルは最終的に選択リストに渡されます。 選択リストは、中間のテーブルのどのを実際に出力するかを決めます。

7.3.1. 選択リスト項目

テーブル式が生成するすべての列を出力する*が最も簡単な選択リストです。 そうでなければ、選択リストは、カンマで区切られた(項4.2で定義された)評価式のリストです。 例えば、以下のような列名のリストであっても構いません。

SELECT a, b, c FROM ...

abcという列名は、FROM句で参照されるテーブルの実際の列名か、あるいは項7.2.1.2で説明したような列名に対する別名です。 グループ化されていなければ、選択リストで使用可能な名前空間はWHERE句と同じです。 グループ化されている場合は、HAVING句と同じとなります。

もし、2つ以上のテーブルで同じ名前の列がある場合は、次のように、テーブル名を必ず指定しなければいけません。

SELECT tbl1.a, tbl2.a, tbl1.b FROM ...

複数のテーブルを使用する場合、特定のテーブルのすべての列を求める方法も便利かもしれません。

SELECT tbl1.*, tbl2.a FROM ...

項7.2.2も参照してください。)

任意の評価式が選択リストで使われる場合、返されるテーブルは、概念的には新たに仮想的な列を追加したものとなります。 評価式は、それぞれの結果行で、その列参照を置換した行の値としていったん評価されます。 しかし、選択リストの式はFROM句で指定されたテーブル式内の列を参照するものである必要はありません。例えば、定数算術式であっても構いません。

7.3.2. 列ラベル

選択リスト中の項目は、ORDER BY句の中での参照、もしくはクライアントアプリケーションによる表示に使うように、それに続く処理のために名前を割り当てることができます。 例を示します。

SELECT a AS value, b + c AS sum FROM ...

もしASを使った列名の指定がなかった場合、システムはデフォルトの列名を割り当てます。 単純な列参照では参照された列名となります。 関数呼び出しでは関数名となります。 複雑な表現についてはシステムが汎用の名前を生成します。

ASキーワードは省略することができますが、新規列名がPostgreSQLキーワード(付録Cを参照)のいかなるものとも一致しない場合のみです。 あるキーワードと予測外の一致を防ぐために、列名を二重引用符で囲むことができます。 例えば、VALUEはキーワードですのでうまく動作しません。

SELECT a value, b + c AS sum FROM ...

しかしこれは動きます。

SELECT a "value", b + c AS sum FROM ...

ありえそうな将来のキーワードの追加に対応するため、ASを記述するか、出力列名を二重引用符で囲むかのいずれかを推奨します。

注意: ここでの出力列の名前は、FROM句(項7.2.1.2を参照)で示したものとは異なります。 同じ列の名前を2度変更することができますが、渡されるのは選択リストの中で割り当てられたものです。

7.3.3. DISTINCT

選択リストが処理された後、結果テーブルの重複行を削除の対象にすることもできます。 これを指定するためには、SELECTの直後にDISTINCTキーワードを記述します。

SELECT DISTINCT select_list ...

DISTINCTの代わりにALLキーワードを指定すると、すべての行がデフォルトで保持されます。)

少なくとも1つの列の値が異なる場合、それら2行は別個とみなされます。 NULL値は、この比較において等しいとみなされます。

また、任意の式を使用して、どの行が別であるかを決定することもできます。

SELECT DISTINCT ON (expression [, expression ...]) select_list ...

expressionは、すべての行で評価される任意の評価式です。 すべての式が等しくなる行の集合は、重複しているとみなされ、集合の最初の行だけが出力されます。 DISTINCTフィルタに掛けられる行の順序の一意性を保証できるよう問い合わせが列を並び替えしない限り、出力される集合の"最初の行"は予想不可能であることに注意してください。 (DISTINCT ON処理は、ORDER BYによる並び替えの後に行われます。)

DISTINCT ON句は標準SQLではありません。 さらに、結果が不定となる可能性があるため、好ましくないスタイルとみなされることもあります。 GROUP BYFROM中の副問い合わせをうまく使うことにより、この構文を使わずに済みますが、DISTINCT ON句はしばしば非常に便利な代案となります。