PostgreSQLにDUALがない理由と代替となるSQLの書き方

PostgreSQLにDUALがない理由と代替となるSQLの書き方：詳細解説

PostgreSQLは、堅牢性、拡張性、標準SQLへの高い準拠性で知られる、世界で最も人気のあるオープンソースのリレーショナルデータベースシステムの一つです。多くのデータベースシステムと比較される中で、Oracle Databaseから移行を検討しているユーザーや、他のデータベースシステムに慣れ親しんだ開発者がしばしば疑問に思う点の一つに、「PostgreSQLにはDUALテーブルがない」という事実があります。

Oracleユーザーにとって、DUALテーブルは単一行の値を返す関数や式を実行したり、一時的な値を生成したりする際に不可欠な存在です。しかし、PostgreSQLでは、そのような用途にDUALテーブルは必要ありません。本記事では、なぜPostgreSQLにDUALテーブルが存在しないのか、その理由をPostgreSQLの設計思想やSQL標準との関係から深く掘り下げます。さらに、OracleのDUAL句が使用される様々なケースに対応する、PostgreSQLでの具体的かつ最適なSQLの書き方を、詳細なコード例と解説を交えて網羅的にご紹介します。この記事を読むことで、PostgreSQLにおけるDUALテーブルの不要性を理解し、DUALに依存しないPostgreSQLらしい、より簡潔で効率的なSQLの記述方法を習得できるでしょう。

はじめに：データベースにおける「DUALテーブル」とは？

まず、DUALテーブルとは具体的にどのようなもので、なぜ特定のデータベースシステムで利用されるのかを理解しましょう。

DUALテーブルは、主にOracle Databaseで利用される、非常に特殊なシステムテーブルです。その構造は極めてシンプルで、単一の列（通常 ‘DUMMY’ という名前）を持ち、単一の行に単一の値（通常 ‘X’）が格納されているだけです。一見すると全く役に立たないように見えるこのテーブルが、Oracleでは多くの場面で利用されます。

DUALの主な役割は、SELECT文でテーブルを指定せずに、計算式の結果、システム関数の値、シーケンスの次の値などを取得するための「ダミーのFROM句」を提供することです。

Oracle Databaseでは、SQLの構文上、SELECT文の多くの場合でFROM句が必須とされています。例えば、現在時刻を取得したい場合、Oracleでは単純にSELECT SYSDATE;とは書けず、SELECT SYSDATE FROM dual;と書く必要があります。計算式の結果を得たい場合も同様に、SELECT 1 + 1;ではなくSELECT 1 + 1 FROM dual;となります。このように、何かしらの値を計算したり取得したりする際に、その対象となるテーブルが存在しない場合でも、Oracleでは構文上の制約からダミーとしてDUALテーブルを指定する必要があったのです。

このDUALテーブルはOracle Databaseのバージョン3から存在しており、長年にわたりOracleユーザーにとって標準的な手法として定着しています。Oracle以外の一部のデータベースシステム、例えばMySQLも、Oracleとの互換性を高める目的でDUALテーブルをサポートしていますが、MySQLでは必ずしもFROM句は必須ではないため、OracleほどDUALへの依存度は高くありません。

一方、PostgreSQLには、このDUALテーブルが標準では存在しません。これはPostgreSQLの設計思想やSQL標準への準拠度に関連しています。次のセクションでは、PostgreSQLにDUALがない根本的な理由を探ります。

PostgreSQLにDUALテーブルが存在しない理由

PostgreSQLにDUALテーブルが存在しない理由は、主に以下の点に集約されます。

SELECT文におけるFROM句の非必須性
標準SQLへの高い準拠性
PostgreSQLの設計哲学

それぞれ詳しく見ていきましょう。

1. `SELECT`文における`FROM`句の非必須性

OracleにDUALテーブルが必要な最大の理由は、SELECT文においてFROM句が構文上必須であるためです。しかし、PostgreSQLではこの制約がありません。PostgreSQLのSELECT文は、少なくとも単純なケースにおいては、FROM句なしで記述することが可能です。

例えば、現在時刻を取得する場合、PostgreSQLでは以下のようにシンプルに記述できます。

sql SELECT now();

または、計算式の結果を取得する場合も同様です。

sql SELECT 1 + 1;

このように、PostgreSQLではリテラル値、計算式の結果、あるいは引数を取らないシステム関数や組み込み関数の結果などを取得する際に、FROM句を省略できます。これは、PostgreSQLのSQLパーサーが、SELECTリストに記述された式や関数呼び出しを、テーブルやリレーションからデータを取得するのではなく、それ自体として評価し、単一行の結果セットとして返すことができるように設計されているためです。

つまり、PostgreSQLではOracleにおけるDUALテーブルの主な役割（FROM句のダミー）が必要となるような構文上の制約が存在しないため、DUALテーブルが不要なのです。

2. 標準SQLへの高い準拠性

PostgreSQLは、SQLの国際標準規格（ISO/IEC 9075）への準拠を重視しています。標準SQLでは、SELECT文のFROM句は必須ではありません。例えば、SQL:1999以降の標準では、VALUES句をテーブルコンストラクタとして使用したり、SELECT文で式の結果を直接取得したりすることが可能です。

PostgreSQLのSELECT文の構文は、このような標準SQLの規定に沿っています。SELECTリストのみで構成されるSELECT文は、標準SQLの精神にも合致しており、PostgreSQLが標準に忠実な実装を目指していることの一端を示しています。

OracleのDUALテーブルは、Oracle独自の拡張機能であり、標準SQLには存在しません。PostgreSQLがDUALを持たないのは、標準にない独自の機能を避け、普遍的なSQLの構文規則を採用している結果とも言えます。

3. PostgreSQLの設計哲学

PostgreSQLの開発コミュニティは、シンプルさ、堅牢性、そして不要なものを排除する思想を重視しています。DUALテーブルのような、特定の構文上の制約を回避するためだけに存在する特殊なオブジェクトは、PostgreSQLの設計哲学から見ると「不要なもの」と映ります。

SQLの基本的な機能、すなわちリテラル、式、関数呼び出しをSELECTリスト内で直接評価できるのであれば、そのためだけに特殊なテーブルを用意する必要はありません。これにより、データベースのカタログがシンプルに保たれ、コードの可読性も向上します（後述しますが、SELECT 1; は SELECT 1 FROM dual; よりも直感的です）。

また、DUALテーブルのようなオブジェクトが存在すると、ごくわずかではあってもシステムリソースを消費し、カタログを肥大化させる要因となります。PostgreSQLは、このような微細なオーバーヘッドも可能な限り排除しようとする傾向があります。

これらの理由から、PostgreSQLではDUALテーブルが設計段階から含まれておらず、必要とされていません。これは、PostgreSQLが独自の道を歩みつつも、標準SQLを尊重し、よりクリーンで柔軟な構文を提供しようとする姿勢の現れと言えるでしょう。

PostgreSQLにおけるDUALの代替手段

PostgreSQLにDUALテーブルがないことが理解できたところで、次にOracleでDUALが使われる様々なケースに対して、PostgreSQLではどのように記述すれば良いのか、具体的な代替手段を見ていきましょう。

PostgreSQLにおけるDUALの代替手段は多岐にわたりますが、そのほとんどはSQLの基本的な構文要素や組み込み関数を利用するものです。主な代替手段は以下の通りです。

SELECT文単独でのリテラル、式、関数呼び出し
VALUES句
システムカタログの利用（非推奨な場合が多いが、移植時に考慮される）
CTE (Common Table Expression)
手続き型言語（PL/pgSQLなど）での代入

それぞれの方法について、詳細な説明と具体的なコード例を挙げながら解説します。

代替手段1: `SELECT`文単独でのリテラル、式、関数呼び出し

これはPostgreSQLで最も一般的かつ推奨される、DUALの代替方法です。前述したように、PostgreSQLではFROM句なしでSELECTリストに直接、リテラル値、計算式、あるいは引数を取らない/引数が自明な関数を記述できます。

構文:

sql SELECT expression; SELECT function_name();

具体例:

固定値（リテラル）の取得:
Oracle: SELECT 'hello' FROM dual;
PostgreSQL:
sql SELECT 'hello';
結果:
?column? ---------- hello (1 row)
計算式の実行:
Oracle: SELECT 1 + 1 FROM dual;
PostgreSQL:
sql SELECT 1 + 1;
結果:
?column? ---------- 2 (1 row)
より複雑な計算も可能です。
sql SELECT (5 * 3) - (8 / 2);
結果:
?column? ---------- 11 (1 row)
現在時刻の取得:
Oracle: SELECT SYSDATE FROM dual; または SELECT CURRENT_TIMESTAMP FROM dual;
PostgreSQL:
sql SELECT now();
または
sql SELECT current_timestamp;
結果 (例):
now --------------------------- 2023-10-27 10:30:00.123456+09 (1 row)
now()はトランザクション開始時刻を返すことが一般的ですが、current_timestampなど、他の時間関数も同様に使えます。
ユーザー名の取得:
Oracle: SELECT USER FROM dual;
PostgreSQL:
sql SELECT current_user;
または
sql SELECT session_user;
結果 (例):
current_user -------------- my_user (1 row)
シーケンスの次の値の取得:
Oracle: SELECT my_sequence.NEXTVAL FROM dual;
PostgreSQL:
sql SELECT nextval('my_sequence');
（my_sequence は事前に作成したシーケンス名とします）
結果 (例):
nextval --------- 101 (1 row)
シーケンスを作成していない場合は、まず作成してください。
sql CREATE SEQUENCE my_sequence START WITH 100;
数学関数の利用:
Oracle: SELECT ABS(-10) FROM dual;
PostgreSQL:
sql SELECT ABS(-10);
結果:
abs ----- 10 (1 row)
他の様々な関数も同様に利用できます。
sql SELECT sqrt(25); SELECT sin(radians(90)); -- 90度のサイン

メリット:

最もシンプルで直感的。
SQLの標準的な機能に近く、他のデータベースシステムでも似た構文がサポートされていることが多い（SQL Serverなど）。
DUALテーブルへのアクセスが全く発生しないため、パフォーマンスが最も優れている（オーバーヘッドがゼロ）。
コードが簡潔で可読性が高い。

デメリット:

この方法では単一の行しか生成できません。複数のリテラル行を生成したい場合は、次のVALUES句が適しています。

このSELECT文単独での方法は、OracleでDUALが使われる最も一般的なユースケースのほとんどをカバーできます。PostgreSQLでDUALの代替を考える際、まずこの方法が適用できないかを検討するのが良いでしょう。

代替手段2: `VALUES`句

VALUES句は、単一行または複数行のデータをリテラル値から構成される「仮想的なテーブル」として生成するための構文です。SQL:1999で導入された標準的な機能であり、PostgreSQLでも完全にサポートされています。DUALテーブルで複数行のダミーデータを扱っていたようなケースや、一時的な少量のデータセットをSQL内で定義したい場合に非常に有効な代替手段です。

構文:

sql VALUES (expression1, expression2, ...), (expressionA, expressionB, ...), ...;

または、サブクエリとして利用する場合:

sql SELECT * FROM (VALUES (expression1, expression2, ...), ...) AS alias_name(column1, column2, ...);

具体例:

単一行の固定値リストの取得:
DUALで似たことをする場合、複数回SELECTしたりUNION ALLを使ったりと複雑になりがちですが、VALUES句は直感的です。
sql VALUES (1, 'apple', true);
結果:
column1 | column2 | column3 ---------+---------+--------- 1 | apple | t (1 row)
複数行の固定値リストの取得:
これはDUALだけでは直接表現できず、UNION ALLなどを使う必要がありますが、VALUES句ならシンプルです。
sql VALUES (1, 'apple'), (2, 'banana'), (3, 'cherry');
結果:
column1 | column2 ---------+--------- 1 | apple 2 | banana 3 | cherry (3 rows)
この例は、DUALテーブルをUNION ALLで結合して複数行を生成していたような場合の直接的な代替となります。
FROM句が必要なコンテキストでの利用（サブクエリとして）:
VALUES句は、それ自体がリレーション（仮想的なテーブル）として扱われます。したがって、FROM句で指定するテーブルの代わりに利用することができます。これにより、SELECT ... FROM dual; の構文に慣れたユーザーが、DUALテーブルなしで同じような構造のクエリを書きたい場合に有効です。
sql SELECT column1 FROM (VALUES (1), (2), (3)) AS tmp(column1);
結果:
column1 --------- 1 2 3 (3 rows)
列名column1はAS tmp(column1)のようにエイリアスで指定できます。エイリアスを指定しない場合、デフォルトの列名（column1, column2など）が使われます。
この形式は、特に他のテーブルと結合したり、サブクエリとして利用したりする際に便利です。例えば、一時的な値リストを使って他のテーブルをフィルタリングする場合などに使えます。
sql -- IDが1または3のユーザーを取得（ユーザーテーブルがあるとして） SELECT * FROM users WHERE user_id IN (SELECT column1 FROM (VALUES (1), (3)) AS tmp(column1));
これはもちろん、より一般的な WHERE user_id IN (1, 3); と同じですが、複雑な値を一時的に生成して利用するシナリオではVALUES句が役立ちます。
式や関数をVALUES句内で利用:
VALUES句の各要素には、リテラルだけでなく式や関数も記述できます。
sql VALUES (1 + 1, now(), sqrt(9));
結果 (例):
column1 | column2 | column3 ---------+-------------------------------+--------- 2 | 2023-10-27 10:35:00.123456+09 | 3 (1 row)

メリット:

複数行、複数列のデータをSQL内で簡単に生成できる。
SQL標準に準拠しており、移植性が高い。
一時的な小さなデータセットを扱うのに非常に便利。
サブクエリやFROM句の中で利用することで、テーブルからの選択と同様の形式でデータを扱える。

デメリット:

単一行の単純な値を取得するだけであれば、SELECT 1; のような構文の方が簡潔。
非常に大きなデータセットを生成するのには向かない（INSERT文と組み合わせる方が一般的）。

VALUES句は、OracleのDUALでは直接的に実現できなかった、複数行・複数列のリテラルデータ生成を、標準的かつ簡潔な構文で可能にします。特にテストデータ生成や、一時的な固定値リストの利用において、非常に強力な代替手段となります。

代替手段3: システムカタログの利用（非推奨な場合が多い）

この方法は、主にOracleからの移行時に、DUALテーブルを使った既存のSQL構文を大きく変えずに済ませたい場合に考慮される古典的なワークアラウンドです。PostgreSQLには、データベースのメタデータ（テーブル情報、型情報、関数情報など）を格納するシステムカタログという特別なテーブル群があります。これらのシステムカタログは常に存在し、通常は少なくとも1行以上のデータを含んでいます（データベースの状態によりますが、pg_catalog.pg_typeやpg_catalog.pg_classのような基本的なカタログは常にデータがあります）。

この性質を利用して、DUALテーブルの代わりにシステムカタログをFROM句に指定し、結果を1行に限定するためにLIMIT 1句と組み合わせるという手法です。

構文:

sql SELECT expression FROM some_system_catalog LIMIT 1;

具体例:

現在時刻の取得（システムカタログ利用）:
sql SELECT now() FROM pg_catalog.pg_type LIMIT 1;
結果 (例):
now --------------------------- 2023-10-27 10:40:00.123456+09 (1 row)
ここではpg_catalog.pg_typeを使っていますが、他の任意のシステムカタログ（例: pg_catalog.pg_class, pg_catalog.pg_procなど）でも同様に機能します。
計算式の実行（システムカタログ利用）:
sql SELECT 1 + 1 FROM pg_catalog.pg_class LIMIT 1;
結果:
?column? ---------- 2 (1 row)

メリット:

OracleのSELECT ... FROM dual; という構文構造を比較的維持できるため、他のデータベースからの移行時の手作業によるコード変更量を減らせる可能性がある。

デメリット:

非推奨: この方法はPostgreSQLでは推奨されません。その理由は以下の通りです。
- 不要なテーブルアクセス: 実際には式や関数の評価だけが必要なのに、システムカタログというテーブルにアクセスし、結果を1行に制限するという無駄な処理が発生します。PostgreSQLのオプティマイザは賢いので、簡単なケースではテーブルアクセスを省略して最適化する可能性もありますが、必ずしも保証されるわけではなく、意図も不明確です。
- 可読性の低下: SELECT now(); と書けば「現在時刻が欲しい」という意図が明確ですが、SELECT now() FROM pg_catalog.pg_type LIMIT 1; は「現在時刻が欲しいけど、なぜか型カタログから1行取ってきてるな…」となり、コードの意図が分かりにくくなります。
- システムカタログへの依存: 使用するシステムカタログが将来のPostgreSQLのバージョンで変更されたり、特定の条件下で予期せず空になる可能性は低いですが、ゼロではありません。純粋なリテラルや関数呼び出しに依存する方がより堅牢です。

このシステムカタログを利用した代替手段は、あくまでOracleからの移行などで、既存のコードベースを短期間で動かす必要があり、かつFROM句を削除する変更が大掛かりになる場合の「応急処置」として考慮されるものです。新規にPostgreSQLでSQLを書く場合は、決してこの方法を使うべきではありません。推奨されるのは、SELECT単独またはVALUES句を利用する方法です。

代替手段4: CTE (Common Table Expression)

CTE（共通テーブル式）は、SQL文内で一時的な結果セットに名前を付ける機能です。複雑なクエリを分割したり、可読性を向上させたりするのに役立ちます。DUALテーブルのように単一の値を生成して、それを後続のクエリで利用したい場合などにもCTEを利用できます。

構文:

sql WITH cte_name AS ( -- 一時的な結果セットを生成するSELECT文 SELECT expression; ) -- CTEを参照するメインクエリ SELECT column_list FROM cte_name WHERE ...;

具体例:

計算結果をCTEとして定義し、メインクエリで利用:
sql WITH calculated_value AS ( SELECT (10 * 5) - 25 AS result ) SELECT result + 5 FROM calculated_value;
結果:
?column? ---------- 30 (1 row)
この例では、calculated_valueというCTEがDUALのように単一行の結果セット（result列を持つ）を生成し、メインクエリがその結果を利用しています。
複数のリテラル値をCTEとして定義し、利用:
VALUES句と組み合わせてCTEを定義することもできます。
sql WITH temp_data AS ( VALUES (1, 'apple'), (2, 'banana') ) SELECT * FROM temp_data;
結果:
column1 | column2 ---------+--------- 1 | apple 2 | banana (2 rows)
より明確にするために、VALUES句で列エイリアスを指定することも可能です。
sql WITH temp_data AS ( VALUES (1, 'apple'), (2, 'banana') AS t(id, name) ) SELECT id, name FROM temp_data WHERE id = 1;
結果:
id | name ----+------- 1 | apple (1 row)

メリット:

複雑なロジックや計算を分割し、クエリ全体の可読性を向上させることができる。
一時的なデータセットに名前を付けて再利用できる。
SQL標準に準拠している。

デメリット:

単純な単一行の値を取得するだけなら、SELECT単独の構文よりも冗長になる。
CTEのスコープは直後のSQL文に限定される。

CTEは、DUALの単純な代替というよりは、より構造化された方法で一時的な値を生成・利用したい場合に適しています。特に、生成した値を複数の箇所で参照する場合などにその真価を発揮します。

代替手段5: 手続き型言語（PL/pgSQLなど）での代入

データベース内の手続き型言語（PostgreSQLの場合は主にPL/pgSQL）を使用する場合、DUALテーブルはさらに不要になります。PL/pgSQLでは、変数を宣言し、計算結果や関数呼び出しの結果をその変数に直接代入するための専用の構文が用意されているからです。

OracleのPL/SQLでは、計算結果を変数に代入する際にSELECT ... INTO ... FROM dual;という構文がよく使われます。

Oracle (PL/SQL):
sql DECLARE my_variable NUMBER := 0; BEGIN SELECT my_variable + 1 INTO my_variable FROM dual; -- DUALが必要 DBMS_OUTPUT.PUT_LINE(my_variable); -- 出力: 1 END; /

PostgreSQLのPL/pgSQLでは、代入演算子:=を使用するか、SELECT ... INTO ...; 構文を使用しますが、どちらもFROM句は不要です。

PostgreSQL (PL/pgSQL):
“`sql
DO $$
DECLARE
my_variable INTEGER := 0;
BEGIN
— 代入演算子を使用する方法（推奨）
my_variable := my_variable + 1;
RAISE NOTICE ‘Variable value: %’, my_variable; — 出力: Variable value: 1

— SELECT INTO を使用する方法（FROM句なし）
SELECT my_variable + 1 INTO my_variable;
RAISE NOTICE ‘Variable value: %’, my_variable; — 出力: Variable value: 2
END $$;
結果 (NOTICEとして):
NOTICE: Variable value: 1
NOTICE: Variable value: 2
“`

メリット:

手続き型言語内で変数を操作する際には、最も自然で直感的な方法。
DUALテーブルのような外部のオブジェクトに依存しない。
代入演算子:=は非常に簡潔。

デメリット:

これはSQL文そのものの代替ではなく、データベースのプログラミング言語内での話。SQL文として単独で実行する用途には使えない。

PL/pgSQL内で計算や関数結果を変数に格納したい場合は、:=演算子またはSELECT ... INTO ...; (FROM句なし) を使うのが標準的な方法であり、DUALテーブルの概念は全く必要ありません。

具体的なユースケースとPostgreSQLでの代替方法のまとめ

DUALが使われる代表的なユースケースと、それに対するPostgreSQLでの推奨される代替方法をまとめておきます。

OracleでのDUAL使用例	PostgreSQLでの推奨される代替方法	解説
`SELECT SYSDATE FROM dual;`	`SELECT now();` または `SELECT current_timestamp;`	`SELECT`単独でシステム関数を実行。
`SELECT 1 + 1 FROM dual;`	`SELECT 1 + 1;`	`SELECT`単独で計算式を実行。
`SELECT my_sequence.NEXTVAL FROM dual;`	`SELECT nextval('my_sequence');`	`SELECT`単独でシーケンス関数を実行。
`SELECT 'Hello World' FROM dual;`	`SELECT 'Hello World';`	`SELECT`単独でリテラルを取得。
`SELECT my_function(arg) FROM dual;`	`SELECT my_function(arg);`	`SELECT`単独でユーザー定義関数を実行。
`INSERT INTO t (col) SELECT 'value' FROM dual;`	`INSERT INTO t (col) VALUES ('value');`	`VALUES`句または`SELECT`単独で値を生成し、`INSERT`する。
`UPDATE t SET col = (SELECT calculated_val FROM dual);`	`UPDATE t SET col = calculated_val;`	サブクエリが単一の値（スカラーサブクエリ）を返すなら、`FROM dual`は不要。
`SELECT * FROM (SELECT 1 AS id FROM dual UNION ALL SELECT 2 FROM dual);`	`VALUES (1), (2);` または `SELECT * FROM (VALUES (1), (2)) AS tmp(id);`	`VALUES`句で複数行データを生成。
`DECLARE ... BEGIN SELECT var + 1 INTO var FROM dual; END;`	`DECLARE ... BEGIN var := var + 1; END;`	手続き型言語では代入演算子または`SELECT INTO` (FROMなし) を使う。

この表からもわかるように、PostgreSQLではDUALテーブルに依存することなく、より直接的かつ簡潔な方法で同等の、またはそれ以上の機能を実現できます。

DUALテーブルの存在がもたらす影響：互換性と移植性

DUALテーブルの有無は、特にOracle DatabaseからPostgreSQLへの移行プロジェクトにおいて顕著な影響を与えます。Oracleで書かれた既存のSQLコードには、DUAL句が至る所に含まれている可能性があります。これらのコードをPostgreSQLで実行するためには、DUAL句を含むSELECT文をPostgreSQLの構文に変換する必要があります。

単純なケース (SELECT function() FROM dual; -> SELECT function();) であれば機械的な置換が可能ですが、より複雑なサブクエリや手続き型言語内のロジックにDUALが組み込まれている場合、手作業での修正や、より高度な変換ツールの利用が必要になることがあります。

例えば、Oracleのストアドプロシージャや関数でDUALに依存している部分は、PostgreSQLのPL/pgSQLの構文（代入演算子やSELECT INTOなど）に合わせて書き換える必要があります。これは、単なる構文置換以上の、手続きロジック全体の理解と修正を伴う作業になる可能性があります。

移行ツールの中には、単純なDUAL句を自動的に削除または変換するものもありますが、すべてのケースに完璧に対応できるわけではありません。したがって、PostgreSQLへの移行を計画する際には、DUAL句の使用状況を把握し、その変換コストを見積もることが重要です。

前述のシステムカタログを利用した代替手段（SELECT ... FROM pg_catalog.pg_type LIMIT 1;）は、Oracleからの移行時に既存コードのFROM句をそのまま残したい場合に一時的に検討されることがありますが、非推奨であり、最終的にはPostgreSQLらしい記述（SELECT ...; や VALUES ...;）に置き換えることが強く推奨されます。これは、コードの可読性、保守性、そして最適なパフォーマンスのためです。

他の主要なデータベースシステムにおけるDUAL

PostgreSQLだけでなく、他の主要なリレーショナルデータベースシステムがDUALテーブルやそれに類するものをどのように扱っているかを知ることは、PostgreSQLの設計思想を相対的に理解する上で役立ちます。

MySQL:
MySQLにはDUALという名前のダミーテーブルが存在します。これは主にOracleからの移行や互換性のために提供されています。しかし、MySQLでもPostgreSQLと同様にSELECT文のFROM句は必須ではありません。例えば、SELECT 1 + 1; や SELECT now(); はMySQLでも有効な構文です。したがって、MySQLにおいてもDUALテーブルは構文上必須ではなく、DUALを使用しない記述が推奨されています。DUALテーブルはInnoDBエンジンで実装されている場合、メモリ上の仮想テーブルとして扱われることが多く、パフォーマンスへの影響は最小限に抑えられています。
SQL Server:
Microsoft SQL Serverには、OracleのDUALテーブルのような特別なダミーテーブルは存在しません。PostgreSQLと同様に、SQL ServerでもSELECT文でFROM句を省略して、リテラル値、計算式、組み込み関数やユーザー定義関数の結果を直接取得できます。例えば、SQL Serverで現在日時を取得するには SELECT GETDATE();、計算をするには SELECT 1 + 1; と記述します。また、複数行のリテラル値を生成するには、PostgreSQLと同様にVALUES句を使用できます（SQL Server 2008以降）。この点において、SQL ServerはPostgreSQLと非常に似たアプローチをとっています。

この比較から、Oracleが歴史的経緯と特定の構文規則からDUALテーブルを持つのに対し、PostgreSQLやSQL Serverといった他の多くの現代的なデータベースシステムは、SELECT文のFROM句を必須としない、より柔軟な構文を採用しており、DUALのようなダミーテーブルを不要としていることがわかります。MySQLは互換性のためにDUALを残していますが、必須ではありません。これは、FROM句の省略可能性が、現代的なSQLの標準的な傾向であることを示唆しています。

パフォーマンスに関する考察

PostgreSQLでDUALテーブルがないことが、パフォーマンスにどのように影響するかについても考察しておきましょう。

OracleでSELECT ... FROM dual;を実行する場合、データベースシステムはDUALテーブルにアクセスし、その単一行を読み取るという処理を行います。DUALテーブルは非常に小さく、通常はメモリ上にキャッシュされるため、このアクセスにかかるコストは極めて小さいです。しかし、それでも物理的なアクセス（たとえメモリ上でも）や、結果セットを返すための内部的な処理が必要です。

一方、PostgreSQLでSELECT expression; や SELECT function(); のようにFROM句を省略して実行する場合、データベースシステムはテーブルに一切アクセスしません。SQLパーサーが文を解析し、その場で式や関数を評価し、その結果を直接クライアントに返します。ここにはテーブルスキャンやインデックススキャン、JOINといった、リレーションに対する操作が一切伴いません。これは、DUALテーブルをスキャンするよりもさらにオーバーヘッドが少ない、究極的に効率的な方法です。

また、VALUES句についても同様に、一時的なリテラル値から構成される仮想的なリレーションを生成するだけで、物理的なテーブルアクセスは発生しません。したがって、VALUES句もパフォーマンスの高い代替手段と言えます。

システムカタログを利用した代替手段（SELECT ... FROM pg_catalog.pg_type LIMIT 1;）の場合は、理論上はテーブルアクセスが発生しますが、PostgreSQLのクエリオプティマイザは非常に高度です。簡単なケースでは、オプティマイザが「このクエリのSELECTリストはテーブルの内容に依存しない」と判断し、FROM句やLIMIT 1句を実質的に無視して、SELECTリストの式や関数だけを評価するような最適化（定数畳み込みや不要句の削除など）を行う可能性があります。しかし、これはオプティマイザの判断に依存するため、常に保証されるわけではありません。また、クエリが少し複雑になると、意図しないプランが選択される可能性もゼロではありません。この点でも、SELECT単独やVALUES句を利用する方が、パフォーマンスの予測可能性が高く、安全です。

結論として、PostgreSQLにDUALテーブルがないことは、単に構文が異なるだけでなく、OracleのDUALを利用するよりも効率的な方法で同じ目的を達成できるというパフォーマンス上のメリットももたらします。最もシンプルで推奨されるSELECT単独の構文は、最もオーバーヘッドの少ない方法です。

可読性とコード規約

DUALテーブルの有無は、コードの可読性やプロジェクト内のコーディング規約にも影響を与えます。

OracleのSELECT SYSDATE FROM dual; という構文は、Oracleユーザーにとっては慣れ親しんだものですが、初めて見る人にとっては「なぜ現在時刻を知るためにdualというテーブルが必要なのだろう？」という疑問を生じさせる可能性があります。

一方、PostgreSQLのSELECT now(); という構文は、「now()関数を実行してその結果を選択する」という意図がより明確で、直感的です。同様に、SELECT 1 + 1; も「計算式1 + 1の結果を選択する」とそのまま理解できます。VALUES (1, 'apple'), (2, 'banana'); も、リテラル値のセットを定義していることが一目でわかります。

このように、PostgreSQLでDUALの代替として推奨される構文は、DUALを使用するよりもコードの意図が明確になり、可読性が向上するというメリットがあります。

プロジェクトでPostgreSQLを使用する場合、DUALテーブルが存在しないことをチーム全体で理解し、DUALに依存しないPostgreSQLらしいSQLの書き方を標準化することが重要です。具体的には、以下の点をコーディング規約として定めることが推奨されます。

単一行の値（計算結果、関数結果、リテラルなど）を取得する場合は、原則としてFROM句を省略し、SELECT expression; または SELECT function(); の構文を使用する。
複数行のリテラル値セットを生成する場合は、VALUES句を使用する。
Oracleからの移行コードでやむを得ずシステムカタログを利用している場合でも、新規コードでは使用せず、段階的にPostgreSQLらしい構文に書き換える計画を立てる。
PL/pgSQL内で変数に値を代入する場合は、代入演算子:=を第一選択肢とする。

このような規約を設けることで、コードベース全体の品質と保守性を高めることができます。

まとめ

PostgreSQLにDUALテーブルが存在しないのは、偶然や実装不足によるものではなく、PostgreSQLの根本的な設計思想と標準SQLへの準拠に起因しています。PostgreSQLでは、SELECT文のFROM句が必須ではないため、OracleでDUALが担っていた「ダミーのテーブル参照」という役割自体が必要ありません。リテラル値、計算式、関数の結果などは、SELECT文のリストに直接記述するだけで取得できます。

DUALテーブルの主な代替手段として、PostgreSQLでは以下の方法が推奨されます。

SELECT文単独でのリテラル、式、関数呼び出し: 最もシンプルで効率的な方法。単一行の結果を得る場合に広く適用可能。
VALUES句: 単一行または複数行のリテラルデータセットを生成する場合に非常に便利。
CTE: 一時的な値を名前付きで定義し、複雑なクエリの可読性を向上させる場合に有効。
手続き型言語での代入: PL/pgSQLなどのプロシージャ内で変数に値を格納する場合の標準的な方法。

システムカタログを利用する方法は、Oracleからの移行時に構文を大きく変えずに済ませるための古典的なワークアラウンドとして存在しますが、PostgreSQLでは非推奨であり、新規コードや既存コードの修正時には避けるべきです。

PostgreSQLのこれらの代替手段は、DUALテーブルを利用するよりも構文が直感的で簡潔であり、物理的なテーブルアクセスが不要なためパフォーマンス面でも優れています。OracleからPostgreSQLへの移行においては、DUAL句の変換がタスクの一つとなりますが、本記事で解説した代替手段を理解することで、スムーズなコードの書き換えが可能になります。

PostgreSQLの設計思想は、不必要な要素を排除し、SQL標準を尊重することで、柔軟かつ堅牢なデータベースシステムを構築することにあります。DUALテーブルの非存在は、まさにその設計思想を反映した特徴の一つと言えるでしょう。DUALがないことに戸惑うのではなく、PostgreSQLが提供するよりシンプルで強力な代替手段を積極的に活用することが、PostgreSQLを最大限に活用する鍵となります。

この記事が、PostgreSQLにおけるDUALテーブルの背景と、その代替となる豊富なSQLの書き方についての理解を深める一助となれば幸いです。PostgreSQLでの開発や運用において、DUALに関する疑問が解消され、より効率的で可読性の高いSQLを書けるようになることを願っています。