SQLite が認識できる SQL

(This page was last modified on 2003/07/20 01:16:48 UTC)

SQLite ライブラリは標準の SQL 言語のほとんどを理解します。 しかし 一部の機能については読み飛ばされ、 また同時にいろいろな機能が少しずつ追加されてきています。 このドキュメントでは SQLite が SQL 言語のどの部分についてサポートしているのか、 もしくはしないのかを解説します。 ドキュメントの最後には キーワード の一覧を付けています。

以下の書式一覧において、リテラルテキストは青のボールド体で示されます。 非端末シンボルは赤のイタリック体で示されます。 演算子それ自体がマークアップ言語書式の一部になるものについては、 黒いローマン体で示しています。

このドキュメントは SQLite で実装されている SQL 文法の概要であるに過ぎません。 多くの低レベルの部品については省略されています。 SQLite 言語が理解する言語の詳細については、 ソースコード、及び文法ファイルである "parse.y" を参照してください。

SQLite では以下の文法を実装しています：

• ATTACH DATABASE
• BEGIN TRANSACTION
• コメント
• COMMIT TRANSACTION
• COPY
• CREATE INDEX
• CREATE TABLE
• CREATE TRIGGER
• CREATE VIEW
• DELETE
• DETACH DATABASE
• DROP INDEX
• DROP TABLE
• DROP TRIGGER
• DROP VIEW
• END TRANSACTION
• EXPLAIN
• 評価式
• INSERT
• ON CONFLICT clause
• PRAGMA
• REPLACE
• ROLLBACK TRANSACTION
• SELECT
• UPDATE
• VACUUM

各コマンドの実装に関する詳細については後述しています。

ATTACH DATABASE

ATTACH DATABASE ステートメントは、 現在のデータベース接続に対して既存のデータベースを追加します。 ファイル名に句読点などが含まれる場合はクォートしなければなりません。 'main' と 'temp' という名前は、それぞれメインのデータベースおよび 一時的なテーブル用として使われるものを参照します。 これらは切り離すことはできません。 接続されたデータベースは DETACH DATABASE ステートメントを使って切り離されます。

ユーザは接続されたデータベースに対して読み書きができますが、 接続されたデータベースのスキーマを変更することはできません。 元のデータベースの中でのみ CREATE や DROP ができます。

接続されたデータベースの中に同じ名前の新しいテーブルを作ることはできませんが、 メインデータベースの中にあるテーブルと重複した名前を持つテーブルを含む データベースを接続するのは構いません。 また、同じデータベースファイルを複数回接続することも許されています。

接続されたデータベースの中にあるテーブルは、 データベース名.テーブル名 という書式を使って参照できます。 接続されたデータベースの中にメインのデータベースと重複するテーブル名が ない場合はデータベース名のプリフィックス（接頭辞）は不要です。 データベースが接続されると、その中で重複しない名前のテーブルはすべて その名前の "デフォルト" テーブルとなります。 その後接続されたそれらの名前のテーブルには、 どれもテーブルプリフィックスが必要となります。 その名前をもつ "デフォルトの" テーブルが切り離されると、 最後に接続されたその名前を持つテーブルが新しいデフォルトになります。

なんらかのデータベースが接続中は、 トランザクションはアトミックにはなりません。 トランザクションは個々のデータベースの中ではアトミックであり続けます。 しかし、あなたのマシンが COMMIT 中にクラッシュし、 その際２つ以上のデータベースを更新していた場合、 これらのファイルのいずれかについては変更が適用され、 それ以外には適用されないという状態があり得ます。

データベースの同時接続数は、コンパイル時に 10 に制限されています。

BEGIN TRANSACTION ステートメントを実行すると、すべてのデータベースをロックします。 このため、この機能は（現在のところ）同時接続性を損ねます。

BEGIN TRANSACTION

バージョン 2.0 の最初の頃、SQLite ではロールバックやアトミックなコミットを伴う トランザクションをサポートしました。接続中のデータベースがある場合の例外については ATTACH を参照してください。

オプションのトランザクション名は無視されます。 SQLite は現時点ではネストしたトランザクションを許していません。 トランザクションの中で別のトランザクションを開始しようとするとエラーになります。

トランザクション中を除いては、データベースに対する変更はできません。 データベースを変更するようなコマンド（基本的には、SELECT を除く SQL コマンド）は、 トランザクションがまだ開始されていなければ、自動的にトランザクションを開始させます。 自動的に開始されたトランザクションは、そのコマンドの終了をもってコミットされます。

トランザクションは BEGIN コマンドによりマニュアルで開始されます。 このようなトランザクションは通常次の COMMIT か ROLLBACK コマンドまで続きます。 しかし、データベースがクローズされたりエラーが発生したりした場合に、 ROLLBACK の衝突解決アルゴリズムが指定されていれば、 トランザクションは ROLLBACK されます。 ROLLBACK の衝突解決アルゴリズムに関する追加情報は、ドキュメントの ON CONFLICT 句をご覧下さい。

BEGIN ステートメントの最後にあるオプションの ON CONFLICT 句によりデフォルトの 衝突解決アルゴリズムを変更できます。通常のデフォルトは ABORT です。 BEGIN の ON CONFLICT で別のものが指定されている場合、 そのトランザクションの中においては、 それがすべてのコマンドのデフォルトとして使われます。 デフォルトのアルゴリズムは、CREATE TABLE や CREATE INDEX ステートメント中の 制約条件に書かれた ON CONFLICT 句、もしくは COPY / INSERT / UPDATE コマンドで上書きされます。

コメント

コメントは SQL のコマンドではありませんが、SQL クエリーの中に現れることが許されています。 これらはパーサによりホワイトスペースとして扱われます。 コメントはホワイトスペースが置けるところならどこから始まってもよく、 複数行にわたっても構いません。

SQL のコメントは高々行末までしか書けません。

C のコメントは何行に渡っても構いません。コメント終端文字列がない場合、 入力の最後までがコメントと見なされます。これはエラーとはなりません。 新しい SQL ステートメントは、複数行コメントの終端の次から始められます。 C のコメントは、ホワイトスペースが置けるところなら式の内部であれ別の SQL 文の途中であれ、どこに埋め込んでも構いません。C のコメントはネスト してはなりません。C コメント中の SQL コメントは、単に無視されます。

COPY

COPY コマンドは、大量のデータをテーブルに取り込むのに使われる拡張機能です。 これは PostgreSQL にある同様のコマンドを元にして作られました。実際、 SQLite の COPY コマンドは PostgreSQL のダンプユーティリティである pg_dump の出力を読み込めるように特別にデザインされていますので、 PostgreSQL から SQLite にデータを持って来るのはとても簡単です。

テーブル名はデータを入れたい既存のテーブルの名前です。 ファイル名はデータを読み込むためのファイルの名前を表す文字列もしくは識別子です。 ファイル名に STDIN を指定すると、データを標準入力から読み込みます。

入力ファイルの各行は、変換されてテーブルの一つの行に入ります。 それぞれのカラムはタブで区切られます。 カラムのデータ中にタブが現れる場合は、 そのタブの前にバックスラッシュ "\" 文字が付きます。 データ中のバックスラッシュは 2 個のバックスラッシュで表されます。 オプションの USING DELIMITERS 句を使うと、 区切り文字をタブ以外のものに変えられます。

カラムが "\N" で構成されている場合、そのカラムには NULL が入れられます。

オプションの CONFLICT 句を指定すると、このコマンドの実行時における 制約違反発生時に使用する代替の解決アルゴリズムを指定できます。 詳細はON CONFLICT のタイトルのついたセクションを見てください。

入力データのソースが STDIN の場合、バックスラッシュとドット "\." だけの行で入力の終了を表します。

CREATE INDEX

CREATE INDEX コマンドの構成は、 "CREATE INDEX" というキーワードに続いて新しいインデックスの名前、 キーワード "ON"、インデックスされるべき既存のテーブルの名前、 そしてインデックスのキーとして使われる、テーブル中のカラム名のリストを 括弧で括ったものとなります。 各カラム名の後にはソート順を指示するための "ASC" または "DESC" という キーワードを置くことができますが、現在の実装ではソート順は無視されます。 ソートは常に昇順に行われます。

一つのテーブルに対して付けられるインデックスの数、 および一つのインデックスで指定できるカラム数についても特に制限はありません。

CREATE と INDEX の間に UNIQUE というキーワードが現れると、 重複したインデックスのエントリを許さなくなります。 重複したエントリを挿入しようとするとエラーとなります。

オプションの CONFLICT 句を指定すると、このコマンドの実行時における 制約違反発生時に使用する代替の解決アルゴリズムを指定できます。 UNIQUE 制約が指定されないと、 このインデックスについては制約条件がなくなってしまいますので、 これは UNIQUE 制約が指定された場合のみ意味を持ちます。 デフォルトのアルゴリズムは ABORT です。もし、COPY / INSERT / UPDATE ステートメントで特定の衝突解決アルゴリズムを指定した場合、 ここで指定されているデフォルトのアルゴリズムがそれで置き換えられます。 詳細はON CONFLICTのタイトルのついたセクションを見てください。

インデックスされるテーブルが一時的なものかどうかによって、 各 CREATE INDEX 宣言時の正確なクエリーテキストがそれぞれ sqlite_temp_master もしくは sqlite_master テーブルに格納されます。 データベースが開かれるたびにすべての CREATE INDEX ステートメントが sqlite_master テーブルから読み込まれ、これを元に SQLite の内部表現におけるインデックスレイアウトが再生成されます。

接続されたデータベースでは、 一時的でないインデックスをテーブルに追加することはできません。 それらはDROP INDEXで削除されます。

CREATE TABLE

CREATE TABLE は、基本的にはキーワード "CREATE TABLE" の後に新しいテーブルの名前、 そしてカラム定義と制約条件を括弧で括ったものが続きます。 テーブル名は識別子かまたは文字列です。 "sqlite_" で始まるテーブル名はエンジンが使うために予約されています。

個々のカラム定義は、カラム名の後にそのカラムのデータ型があり、 オプションで一つ以上の制約条件が続きます。しかしながら、SQLite には 型がありません。 このため、カラムのデータ型によってそのカラムに格納されるデータが制限される といったことはありません。 すべての情報は NULL で終端された文字列に格納されます。 UNIQUE 制約は、指定されたそのカラムをキーとするインデックスを生成します。 このインデックスは一意のキーを含んでいなければなりません。 DEFAULT 制約はデータを挿入する再のデフォルト値を指定します。

PRIMARY KEY（主キー）を指定しても、 通常は単に主キーに対してユニークなインデックスを生成するだけです。 しかしながら、主キーが INTEGER データ型を持つ単独のカラムで構成される場合、 内部的にはそのカラムはそのテーブルの B ツリーにおける実際のキーになります。 つまり、そのカラムは一意の整数値だけを保持できるということです。（ただし、 SQLite はカラムのデータ型の指定を無視し、そのカラムがどういうデータ型として 宣言されているかにかかわらず、いかなる種類のデータをも格納できてしまいますので、 その場合はこの限りではありません。）INTEGER PRIMARY KEY の属性を持つカラム がないテーブルの場合 、B ツリーキーは自動的に生成される整数となります。 ある行の B ツリーのキーは、特別な名前である "ROWID", "OID", "_ROWID_" のいずれかを使うことで常にアクセスできます。この機能は INTEGER PRIMARY KEY の有無にかかわらず有効です。

"CREATE" と "TABLE" の間に "TEMP" もしくは "TEMPORARY" （一時的）という キーワードがある場合、生成されるテーブルはそのデータベースを開いたプロセス のみからしか見えなくなり、データベースが閉じられると自動的に削除されます。 一時テーブルに対して生成されたインデックスも一時的なものになります。 一時テーブルおよびインデックスは、メインのデータベースとは独立した別の ファイルに格納されます。

各制約条件の次にオプションでCONFLICT 句を指定すると、その制約における デフォルトの制約衝突時解決アルゴリズムの代替となるものを指定できます。 デフォルトは ABORT です。１つのテーブルに異なった制約条件がある場合、 異なったデフォルト衝突時解決アルゴリズムが存在することになることも あります。もし COPY / INSERT / UPDATE コマンドでそれぞれ異なった 衝突時解決アルゴリズムを指定している場合、CREATE TABLE ステートメントで 指定されたデフォルトのアルゴリズムに代わり、それらのアルゴリズムが 使われます。 詳細はON CONFLICTのタイトルのついたセクションを見てください。

CHECK 制約は現時点の実装では無視されます。CHECK 制約のサポートは、 将来実装される可能性があります。version 2.3.0 においては、NOT NULL, PRIMARY KEY, UNIQUE 制約はすべて動きます。

あるテーブルにおいて、カラム数や制約数が勝手に制限されることはありません。 単一の行に格納できるデータの総量は、約 1MB に制限されています。 （ソースコードの中で #define を一箇所変えて再コンパイルすることで、 この制限は 16MB まで緩和できます）

CREATE TABLE AS の書式は、あるクエリーの結果セットをそのままテーブルと することを定義します。テーブルのカラム名はその結果セット内のカラム名と なります。

それぞれの CREATE TABLE ステートメントの正確なクエリー文が sqlite_master テーブルに格納されます。 データベースが開かれるたびにすべての CREATE TABLE ステートメントが sqlite_master テーブルから読み込まれ、これを元に SQLite の内部表現におけるテーブルレイアウトが再生成されます。 元のコマンドが CREATE TABLE AS だった場合、これと同等の CREATE TABLE ステートメントが組み立てられ、元のコマンドに代わって sqlite_master に格納されます。 CREATE TEMPORARY TABLE ステートメントのクエリー文は sqlite_temp_master テーブルに格納されます。

テーブルを削除するには DROP TABLE ステートメントを 使います。接続中のデータベースに属する一時的でないテーブルは削除できません。

CREATE TRIGGER

CREATE TRIGGER ステートメントはデータベーススキーマに対してトリガを 追加するのに使われます。トリガは、指定されたデータベースイベント （データベースイベント）が発生した時に自動的に実行されるデータベース操作 （トリガーアクション）です。

トリガは、特定のデータベーステーブルに対する DELETE / INSERT / UPDATE が 行われたか、もしくはある特定のテーブルの中の指定された１つ以上のカラムが UPDATE により更新されたタイミングで起動するようにできます。

現時点では SQLite は FOR EACH ROW トリガのみをサポートし、 FOR EACH STATEMENT トリガはサポートしていません。 そのため明示的に FOR EACH ROW を書くのはオプション扱いになっています。 FOR EACH ROW は、トリガーステップ として指定された SQL 文が、 INSERT / UPDATE / DELETE されようとしている各データベースの行に対し、 起動されたトリガの発生原因となったステートメントにより（ WHEN 句に従って） 実行されることを暗に示しています。

WHEN 句と トリガーステップ は、いずれも INSERT / UPDATE / DELETE されようとしている行の要素に、それらを参照するための "NEW.カラム名" と "OLD.カラム名" という書式を使ってアクセスすることができます。 ここで カラム名 はトリガが関連付けられているテーブルのカラムの名前です。 OLD と NEW 参照は トリガーイベント のうちのいずれか適切な個所（下記を参照） のみで使うことができます。

WHEN 句が指定された場合、トリガーステップ として指定された SQL ステートメントは WHEN 句が真となる行のみで実行されます。WHEN 句が指定されない場合、 SQL ステートメントはすべての行で実行されます。

トリガータイミング（訳注：[ BEFORE | AFTER ]）は、関連する行への挿入、更新、 削除の前後どちらでトリガーステップ を実行するのかを指定します。

INSERT または UPDATE の トリガーステップ の一部として ON CONFLICT 句を指定できます。しかしながら、実行されるトリガの要因となるステートメント の方でも ON CONFLICT 句が指定されている場合、後者の衝突処理ポリシーの方が 代わりに使われます。

あるテーブルが削除されると、それらに関連するトリガも自動的に削除されます。

CREATE TRIGGER ステートメントに INSTEAD OF を指定することで、 通常のテーブルだけでなくビューに対してもトリガを定義することができます。 ひとつのビューに対して１つ以上の ON INSERT / ON DELETE / ON UPDATE トリガを定義できます。こうすると、ビューに対して INSERT / DELETE / UPDATE を実行してもエラーになりません。ビューに対する INSERT / DELETE / UPDATE が、 それぞれに関連するトリガを起動するようになるのです。それらのビューの元になる 実際のテーブルは（トリガ内で明示的に行わない限り）変更されません。

例：

"customers" テーブルに顧客レコードが入っており、その注文レコードが "orders" テーブルに入っているとします。以下のトリガを定義して、顧客が自分の住所を 変更したとき、関連するすべての注文の宛名が書き換わるようにしてみましょう：

CREATE TRIGGER update_customer_address UPDATE OF address ON customers 
  BEGIN
    UPDATE orders SET address = new.address WHERE customer_name = old.name;
  END;

このトリガをインストールしてから、以下のステートメントを実行すると：

UPDATE customers SET address = '1 Main St.' WHERE name = 'Jack Jones';

以下のクエリーが自動的に実行されます：

UPDATE orders SET address = '1 Main St.' WHERE customer_name = 'Jack Jones';

注意：現時点では、INTEGER PRIMARY KEY フィールドを持つテーブルに対してトリガを 定義すると、妙な振る舞いをすることがあるようです。トリガ起動のきっかけとなる ステートメントによって事後に更新される行の中の INTEGER PRIMARY KEY フィールドを BEFORE トリガが変更する場合、更新が行われないことがあります。 これは、テーブル定義の際 INTEGER PRIMARY KEY ではなく PRIMARY KEY でカラムを定義しておくという方法で回避できます。

トリガプログラムに対して、以下の書式により特別な RAISE() という SQL 関数を 使うことができます。

トリガプログラムの実行中に最初の３つの書式のいずれかが呼び出されると、 指定された ON CONFLICT 処理（ABORT / FAIL / ROLLBACK のいずれか）が 実行され、現在のクエリーは終了します。ユーザには指定されたエラー メッセージとともに SQLITE_CONSTRAINT のエラーコードが返されます。

RAISE(IGNORE) が呼ばれると、現在のトリガプログラムの残りの部分、 実行されたトリガプログラムの起動要因となったステートメント、 およびこれに続く実行されるべきだったトリガプログラムは中止されます。 データベースの変更はロールバックされません。 実行されたトリガプログラムの起動要因となったステートメントそれ自身が トリガプログラムの一部だった場合、 そのトリガプログラムの実行はその次のステップから再開されます。

トリガを削除するには DROP TRIGGER を使います。 接続中のデータベース内のテーブルに一時的でないトリガを定義することはできません。

CREATE VIEW

CREATE VIEW コマンドは事前にパッケージされた SELECT ステートメントに名前を割り当てます。いったんビューが作られると、 それは別の SELECT の FROM 句において、テーブル名の代わりに使えます。

ビューに対する COPY / DELETE / INSERT / UPDATE はできません。 SQLite ではビューはリードオンリーです。しかしながら、多くのケースにおいては ビューに対して TRIGGER を使うことで同じことを実現 できます。ビューは DROP VIEW コマンドで削除されます。 接続中のデータベース内のテーブルに一時的でないビューを定義することはできません。

DELETE

DELETE コマンドはテーブルからレコードを削除します。書式としては、"DELETE FROM" コマンドに続けて削除したいレコードを持つテーブル名を指定します。

WHERE 句をつけないと、そのテーブルのすべての行が削除されます。 WHERE 句が指定されると、その評価式にマッチする行だけが削除されます。

DETACH DATABASE

このステートメントは ATTACH DATABASE ステートメントによって 以前に接続された追加のデータベースコネクションを切り離す。同じデータベース ファイルを違う名前で複数回接続することも可能であり、あるファイルへのコネクションを 切り離してもほかの接続には影響を与えない。

SQLite がまだトランザクションの途中だった場合、このステートメントは失敗する。

DROP INDEX

DROP INDEX ステートメントは CREATE INDEX ステートメントで追加されたインデックスを削除します。 指定されたインデックスはディスクから完全に削除されます。 インデックスを修復する唯一の方法は、適切な CREATE INDEX コマンドを再度投入することです。 接続中のデータベース内のテーブルに対する一時的でないインデックスは削除できません。

DROP TABLE

DROP TABLE ステートメントは CREATE TABLE ステートメントで追加されたテーブルを削除します。 名前にはテーブル名を指定します。 これはデータベーススキーマとディスクファイルから完全に削除されます。 テーブルを修復する手段はありません。 そのテーブルに関連するインデックスもすべて削除されます。 接続中のデータベース内の一時的でないテーブルは削除できません。

DROP TRIGGER

DROP TRIGGER ステートメントは CREATE TRIGGER ステートメントで生成されたトリガを削除します。 指定されたトリガはデータベーススキーマから削除されます。 注意：トリガは、関連するテーブルが削除された時、自動的に削除されます。 接続中のテーブルで、一時的でないトリガは削除できません。

DROP VIEW

DROP VIEW ステートメントは CREATE VIEW ステートメントで生成されたビューを削除します。 名前にはビュー名を指定します。 指定されたビューはデータベーススキーマから削除されますが、 元になったテーブルにある実データが変更されることはありません。 接続中のデータベースにおいて、一時的でないビューは削除できません。

EXPLAIN

EXPLAIN コマンド修飾子は非標準の拡張機能です。 このアイデアは PostgreSQL の似たようなコマンドから得ていますが、 その動作は全く異なります。

SQLite の SQL コマンドの前に EXPLAIN キーワードが現れると、 実際にその SQL コマンドを実行する代わりに、SQLite ライブラリは EXPLAIN がなければ実行されるはずだった一連の仮想マシン命令を報告します。 仮想マシン命令に関する詳細は、その仮想マシンに関する アーキテクチャの説明(architecture description) または 使用できるオペコード(available opcodes) をご覧下さい。

評価式

このセクションはほかのものとは異なります。このドキュメントの中で、 ほかのほとんどのセクションでは特定の SQL コマンドについて解説しています。 このセクションでは単独のコマンドについて述べるのではなく、 ほかのほとんどのコマンドの一部となる『評価式』について説明します。

SQLite は以下の二項演算子を理解します。 上にあるものほど優先順位が高くなっています：

||
*    /    %
+    -
<<   >>   &    |
<    <=   >    >=
=    ==   !=   <>   IN
AND   
OR

サポートしている単項演算子は以下の通りです：

-    +    !    ~

SQLite のどんな値でも評価式の一部にすることができます。 算術演算においては整数は整数として扱われます。 文字列はまず atof() で実数に変換されます。 比較演算子においては、数値は数値として比較し、 文字列の比較では strcmp() 関数が使われます。 等号と不等号にはそれぞれ 2 つのバリエーションがあるので注意してください。 等号は= または == です。 不等号は!= または <> です。 || 演算子は『文字列の連結』です - オペランドである 2 つの文字列を結合します。 % 演算子は左辺を右辺で割った余りを出力します。

LIKE 演算子はワイルドカードによる比較を行います。 右辺のオペランドにはワールドカードを含みます。 右辺の中のパーセント文字 % は、 左辺にある 0 個以上の任意の文字の並びにマッチします。 右辺の中のアンダースコア _ は、 左辺にある 1 個の任意の文字にマッチします。 LIKE 演算子は大文字小文字を区別しないので、 片方にある大文字と反対側の小文字がマッチしてしまいます。 （バグ：SQLite は 7 bit LATIN 文字の場合のみ大文字小文字を理解します。 たとえば 'a' LIKE 'A' という式は真になりますが 'æ' LIKE 'Æ' は偽になります。） 中置の LIKE 演算子は like(X,Y) ユーザ関数とは別物です。

GLOB 演算子は LILE に似ていますが、 こちらはワイルドカードに UNIX ファイルのグロビングの書式を使います。 また GLOB は LIKE とは異なり大文字小文字を区別します。 GLOB も LIKE も頭に NOT をつければ条件の意味が反対になります。 中置の GLOB 演算子はユーザ関数 glob(X,Y) とは別物です。

カラム名には CREATE TABLE ステートメントで定義された名前のいずれか、 または特殊な識別子である "ROWID", "OID", "_ROWID_" のいずれかを指定します。これらの特殊な識別子は、どれも各テーブルの各行に 関連付けられたユニークでランダムなキー（"行キー"）を表します。 CREATE TABLE ステートメントで同じ名前を持つ実際のカラムを定義しない場合、 これらの特殊な識別子は行キーだけを参照します。 行キーはリードオンリーのカラムのように振舞います。 行キーは通常のカラムを書けるところであればどこででも使えます。 ただし行キーの値を UPDATE や INSERT ステートメントで変更することはできません。 "SELECT * ..." では行キーの値は返しません。

SQLite は Oracle8 の外部結合動作を最小限サポートしています。 "カラム名" もしくは "テーブル名.カラム名" という評価式の後に特別の "(+)" 演算子を付けることができます。 カラム評価式のテーブルが結合において２番目もしくは後続のテーブルである場合、 そのテーブルは LEFT OUTER JOIN の左辺のテーブルになります。 このテーブルを使う評価式は、この結合に関する ON 句の一部となります。 Oracle8 の振る舞いが忠実に実装されているわけではありませんが、 SQLite と Oracle 双方で正しく動作するクエリーを構築することはできます。

評価式の中の IN 演算子の右辺オペランドもしくはスカラー値の並びのところに SELECT ステートメントを書くことができます。いずれの場合においても、その SELECT では結果セットにひとつのカラムだけを持つようにしなければなりません。 ここには（ UNION または EXCEPT のようなキーワードで結合された）SELECT の 合成物を書いても構いません。評価式の中の SELECT はほかのすべての処理が 行われる前に一度だけ評価されますので、SELECT 自身の中に書かれた評価式は どれも入っている評価式の中のデータを参照しません。

SELECT が IN 演算子の右辺オペランドの場合、左辺の評価結果が SELECT が 生成した値のいずれかであれば真が返されます。IN 演算子の前に NOT が 置かれると、そのテストの意味が反対になります。

SELECT が IN 演算子の左辺以外の評価式中に現れると、その SELECT の結果の 最初の行が評価式で使われる値になります。SELECT が複数の行を返した場合、 先頭行以外はすべて無視されます。SELECT が全く行を返さない場合、その SELECT の値は NULL になります。

関数については単純なもの、および集約されたもののいずれもサポートされて います。単純な関数はどの評価式の中でも使えます。単純な関数は、その入力 に応じて即座に値を返します。集約関数は SELECT ステートメントの中だけで 使われます。集約関数は結果セットの行すべてについて、それらの結果を計算 します。

以下の関数はデフォルトで有効になっています。また追加の関数を C で書き、 sqlite_creat e_function() API を使ってデータベースエンジンに追加することもできます。

以下の集約関数はデフォルトで使用可能になっています。C で書かれた追加の 集約関数が sqlite_create_aggregate() API を使って追加可能です。

INSERT

INSERT ステートメントには２つの基本的な書式があります。（"VALUES" キーワード を書く）最初の書式では、既存のテーブルに単一の新しい行を作成します。 カラムの並びが指定されない場合、値の数がそのテーブルのカラム数と等しく なければなりません。カラムの並びが指定された場合、値の数が指定された カラム数と合っていなければなりません。テーブルのカラムがカラム並びに 現れない場合はデフォルト値がセットされ、デフォルト値が指定されていない 場合には NULL がセットされます。

INSERT ステートメントの２番目の書式は、SELECT ステートメントからの データを取り込みます。 SELECT 結果のカラム数は、カラム並びにおける カラム数に合致しているか、もしくはカラムの並びを指定しない場合、 対象テーブルのカラム数と完全に一致していなければなりません。 SELECT はシンプルなものでも複合的なものでも構いません。 もしその SELECT ステートメントに ORDER BY 句が含まれている場合でも、 ORDER BY は無視されます。

オプションの CONFLICT 句を指定すると、このコマンドを使う場合に限って使われる、 代替の制約となる衝突時解決アルゴリズムを指定できます。詳細は ON CONFLICTのタイトルのついたセクションを見てください。 パーサでは MySQL との互換性のために "INSERT OR REPLACE" の別名としての REPLACE というキーワードを認めています。

ON CONFLICT 句

ON CONFLICT 句は独立した SQL コマンドではありません。 これはほかの多くの SQL コマンドの中に現れてもよい、非標準の句です。 これは標準 SQL の一部ではなく、 それゆえあまりなじみがないと思われますので、 この文書でも一つのセクションを割いて解説を行っています。

ON CONFLICT 句の書式については前述の CREATE TABLE, CREATE INDEX, および BEGIN TRANSACTION コマンドのところですでに述べています。 COPY, INSERT, UPDATE コマンドについては書式をより自然にするため、 "ON CONFLICT" というキーワードは "OR" で置き換えられています。 しかし、どちらでも句の意味自体に変わりはありません。

ON CONFLICT 句は、制約衝突を解決するために使われるアルゴリズムを指定します。 選択肢としては、ROLLBACK, ABORT, FAIL, IGNORE, REPLACE の５つがあります。 デフォルトのアルゴリズムは ABORT です。それぞれの意味は以下の通りです：

ROLLBACK

制約違反が起こったら即座に ROLLBACK します。つまり、 現在のトランザクションを終了させ、 コマンドは SQLITE_CONSTRAINT コードを返します。 （各コマンドにより生成される暗黙のトランザクションを除いて） トランザクションが実行中でなければ、 このアルゴリズムは ABORT と同じように動きます。

ABORT

制約違反が起こったら、そのコマンドがそれまでに行った変更操作は取り消され、 そのコマンドは SQLITE_CONSTRAINT コードを返します。 ただし ROLLBACK が行われるわけではないので、 同じトランザクション内で実行されたそれ以前のコマンドの実行結果は保持されます。 これはデフォルトの振る舞いです。

FAIL

制約違反が起こったら、コマンドは SQLITE_CONSTRAINT コードを返します。 ただし、そのコマンドが制約違反となる前に行われたデータベースへの変更は保持され、 取り消されることはありません。たとえば、UPDATE コマンドが更新を行って 100 行目で制約違反が起こった場合、最初から 99 行目までの変更は有効になり、 100 行目以降への変更は行われません。

IGNORE

制約違反が起こったら、制約違反の原因となったその１行については INSERT や UPDATE が行われません。ただし、そのコマンドはそれ以降も正常に実行を続けます。 制約違反が起こったその行以外行は通常通り INSERT や UPDATE が行われます。 エラーは返されません。

REPLACE

UNIQUE 制約違反が起こった場合、制約違反の原因となった既存の行は、 現在行の INSERT や UPDATE に先立って削除されます。そのため、 INSERT や UPDATE は常に行われ、コマンドは通常動作を続けます。 エラーは返されません。 NOT NULL 制約違反が起こった場合、その NULL 値はそのカラムのデフォルト値に 置き換えられます。そのカラムにデフォルト値が設定されていなかった場合には ABORT アルゴリズムが適用されます。

この衝突解決方法が、制約動作を満足させるために行を削除する場合、 その行については削除トリガが起動されることはありません。 しかしこの動作は将来変更される可能性があります。

衝突解決アルゴリズムは以下の位置に指定できます。なお、 優先度の最も低いものから最も高いものの順に示しています：

1. CREATE TABLE や CREATE INDEX の中で、個別の制約条件として。

2. BEGIN TRANSACTION コマンド。

3. COPY, INSERT, UPDATE コマンドの OR 句。

COPY, INSERT, UPDATE コマンドの OR 句で指定されたアルゴリズムは BEGIN TRANSACTION コマンドで指定されたアルゴリズムをオーバーライドし、 BEGIN TRANSACTION コマンドで指定されたアルゴリズムは CREATE TABLE や CREATE INDEX の中で指定されたアルゴリズムをオーバーライドします。 アルゴリズムが全く指定されない場合、ABORT アルゴリズムが使われます。

PRAGMA

PRAGMA コマンドは SQLite ライブラリの動作を変更するために使われます。 プラグマコマンドは実験的なものなので、SQLite の将来のバージョンでは特定の プラグマステートメントがなくなったり、新たに追加されたりすることがあります。 このコマンドを使う際には注意が必要です。

整数値を取る PRAGMA には、シンボル名を指定することもできます。 文字列 "on", "true", "yes" は 1 と同じです。 文字列 "off", "false", "no" は 0 と同じです。 これらの文字列は大文字小文字を区別せず、また引用符で括る必要もありません。 認識できない文字列は 1 として扱われ、エラーにはなりません。 値 が返される場合、その値は整数として返されます。

現在の実装では以下のプラグマがサポートされています：

• PRAGMA cache_size;
  PRAGMA cache_size = ページ数;

  SQLite がメモリ上で一度に確保するデータベースのディスクページの最大数を 参照または変更します。各ページではおよそ 1.5K のメモリを消費します。 デフォルトのキャッシュサイズは 2000 です。データベースの大量の行を変更する UPDATE または DELETE を行う際に SQLite がより多くのメモリを消費しても構わない 場合、キャッシュサイズを増やしてやれば速度的に有利になることがあります。

  cache_size プラグまでキャッシュサイズの変更をしても、変更は現在のセッション にのみ適用されます。データベースが閉じられその後再度オープンされた時点で キャッシュサイズはデフォルト値に戻ります。永続的なキャッシュサイズをチェック するには default_cache_size を使います。

• PRAGMA count_changes = ON; (1)
  PRAGMA count_changes = OFF; (0)

  ON の場合、DELETE, INSERT, UPDATE が行われるたびに COUNT_CHANGES は 一度づつコールバック関数を呼び出します。引数は変更された行数です。

  このプラグマは SQLite の将来のバージョンではなくなる可能性もあります。 sqlite_changes() API 関数の使用を検討してみてください。

• PRAGMA database_list;

  各データベースをオープンするごとに、そのデータベースに関する情報を元に 一度づつコールバック関数が呼ばれます。引数には接続されたデータベースの 名前とインデックスが含まれます。最初の行はメインデータベースのためのものです。 ２番目の行は一時的なテーブルを格納するのに使われるデータベースのためのものです。

• PRAGMA default_cache_size;
  PRAGMA default_cache_size = ページ数;

  SQLite がメモリ上で一度に確保するデータベースのディスクページの最大数を 参照または変更します。各ページではディスク上で 1K そしてメモリ上では 1.5K を消費します。このプラグマは cache_size と同じように働きますが、さらに永続的なキャッシュサイズを変更することができます。 このプラグマで一度キャッシュサイズを変更するとその変更内容は保持され、 そのデータベースを再度オープンするたびにその値が再利用されます。

• PRAGMA default_synchronous;
  PRAGMA default_synchronous = FULL; (2)
  PRAGMA default_synchronous = NORMAL; (1)
  PRAGMA default_synchronous = OFF; (0)

  データベースの "synchronous（同期）" フラグを参照または変更します。 最初の（問い合わせの）形式では設定値を整数で返します。 synchronous が FULL(2) の場合、SQLite データベースエンジンはデータベースが 実際にディスク表面に書き込まれるまで確実に待ち合わせを行い、それから次の 処理に進みます。これにより、オペレーティングシステムがクラッシュしたり 電源が落ちたりした場合、リブート後にデータベースが整合を保つことを保証します。 FULL synchronous はとても安全ですが、その分遅いです。
  synchronous が NORMAL（1：デフォルト値）の場合、SQLite データベースエンジンは データベースが実際にディスク表面に書き込まれるまでの中の非常に重要な部分のみ 待ち合わせを行いますが、FULL モードほど長くは待ちません。NORMAL モードでは、 電源断が発生した場合、データベースが壊れるタイミングがわずかながら （しかし０ではありません）存在します。ただ実際のところ、ディスク障害や 復旧不能なハードウェア障害で悩むことの方が、確率的にはより大きいでしょう。 このため NORMAL がデフォルトのモードとなっています。
  synchronous が OFF(0) の場合、データをオペレーティングシステムに渡した後、 SQLite は一切待ち合わせを行いません。SQLite が動いているアプリケーションが クラッシュした場合ならデータは無事ですが、オペレーティングシステムがクラッシュ したり、データがディスクの表面に書かれるまでに電源断が起こった場合、 データベースが損傷する場合があり得ます。その代わり synchronous OFF にすると、 オペレーティグシステムによっては 50 倍以上高速化されます。

  このプラグマは同期モードを恒常的に変更します。いったん変更されると、 データベースを閉じて再度オープンしても、そのモードは変更されません。 synchronous でも同じことができますが、 この場合は現在のセッションの設定だけに適用されます。

• PRAGMA default_temp_store;
  PRAGMA default_temp_store = DEFAULT; (0)
  PRAGMA default_temp_store = MEMORY; (2)
  PRAGMA default_temp_store = FILE; (1)

  データベースの "temp_store" フラグを参照または変更します。temp_store が DEFAULT (0) の場合、一時的なデータベースにはコンパイル時のデフォルト値が 適用されます。temp_store が FILE (1) の場合、ディスク上の一時データベース ファイルが使われます。ライブラリのコンパイル時オプションによりこの設定を オーバーライドすることも可能ですので注意してください。いったん一時 データベースが使われると、その場所を変更できなくなります。

  このプラグマは temp_store モードを恒久的に変更します。いったん変更されると、 データベースを閉じて再度オープンしても、このモードは変更されません。 temp_store でも同じことができますが、 この場合は現在のセッションの設定だけに適用されます。

• PRAGMA empty_result_callbacks = ON; (1)
  PRAGMA empty_result_callbacks = OFF; (0)

  ON の場合、EMPTY_RESULT_CALLBACKS プラグマは結果セットが空であるような クエリーが発行されるたびにコールバック関数を呼び出します。 コールバック関数に対する３番目のパラメータ "argv" には 報告するべきデータがないので NULL がセットされます。ただし２番目の "argc" と４番目の "columnNames" パラメータは有効であり、 これらにより結果セットにおいて空ではないカラムの数や名前を決定するのに 使われます。

• PRAGMA full_column_names = ON; (1)
  PRAGMA full_column_names = OFF; (0)

  SQLite のコールバック関数で報告されるカラム名は、"テーブル名.カラム名" の形式が使われない限り、単にカラムの名前そのものです。しかし full_column_names が ON にされると、単純なクエリーにおいてもカラム名は 常に "テーブル名.カラム名" 形式で報告されます。

• PRAGMA index_info(インデックス名);

  指定されたインデックスが参照する各カラムについて、そのカラムの名前と 番号を含む情報を伴い、コールバック関数が呼ばれます。

• PRAGMA index_list(テーブル名);

  指定されたテーブルのインデックスについて、そのインデックスに関する 情報を伴い、コールバック関数が呼ばれます。引数にはインデックス名と そのインデックスがユニークであるかどうかを示すフラグを含まれます。

• PRAGMA integrity_check;

  このコマンドはデータベース全体の整合性チェックを行います。 順序が誤っているレコードや見つからないページ、不正なレコードや インデックスを探し、何らかの問題が見つかれば問題の内容を示す文字列を 返します。すべてが正しければ "ok" が返されます。

• PRAGMA parser_trace = ON; (1)

  SQLite ライブラリ内部における SQL パーサのトレース機能を ON / OFF します。 これはデバッグ目的で使われます。これは NDEBUG マクロを指定しないで コンパイルされたライブラリの場合にのみ使えます。

• PRAGMA show_datatypes = ON; (1)
  PRAGMA show_datatypes = OFF; (0)

  ON の場合、SHOW_DATATYPES プラグマは sqlite_exec() コールバック 関数の第４引数 ("columnNames") に追加される、カラムの データ型 の名前を含む特別なエントリを作ります。 OFF の場合、コールバック関数への第４引数にはカラム名だけが入ります。 テーブルのカラムのデータ型は、テーブルを定義するための CREATE TABLE ステートメントから持ってきます。データ型が指定されていないカラムには "NUMERIC" データ型が割り当てられ、評価式の結果にはその評価式に従い "TEXT" または "NUMERIC" データ型が返されます。 以下に、"SELECT 'xyzzy', 5, NULL AS empty " というクエリーを発行した 場合の違いを示します：

  show_datatypes=OFF		show_datatypes=ON
  azCol[0] = "xyzzy"; azCol[1] = "5"; azCol[2] = "empty"; azCol[3] = 0;		azCol[0] = "xyzzy"; azCol[1] = "5"; azCol[2] = "empty"; azCol[3] = "TEXT"; azCol[4] = "NUMERIC"; azCol[5] = "TEXT"; azCol[6] = 0;

• PRAGMA synchronous;
  PRAGMA synchronous = FULL; (2)
  PRAGMA synchronous = NORMAL; (1)
  PRAGMA synchronous = OFF; (0)

  現在のデータベース接続における、データベースの "synchronous" フラグを参照または変更します。データベースが閉じられ再度オープンされると、 synchronous フラグはデフォルト値に戻ります。synchronous フラグに関する 詳細は default_synchronous プラグマの説明をご覧下さい。

• PRAGMA table_info(テーブル名);

  指定されたテーブルのそれぞれのカラムについて、カラムの名前、データ型、 カラムが NULL 値を許すかどうか、そのカラムのデフォルト値といった情報 を含む値を伴い、コールバック関数を一度づつ呼び出します。

• PRAGMA temp_store;
  PRAGMA temp_store = DEFAULT; (0)
  PRAGMA temp_store = MEMORY; (2)
  PRAGMA temp_store = FILE; (1)

  現在のデータベース接続に影響を与える、データベースの "temp_store" フラグを参照または変更します。データベースが閉じられ再度オープンされると、 temp_store フラグはデフォルト値に戻ります。temp_store フラグに関する 詳細は default_temp_store プラグマの説明をご覧下さい。

• PRAGMA vdbe_trace = ON; (1)
  PRAGMA vdbe_trace = OFF; (0)

  SQLite 内部の仮想データベースエンジンのトレース機能を ON / OFF します。 これはデバッグ用に使われるものです。詳細は VDBE documentation をご覧下さい。

未定義のプラグマが発行されてもエラーメッセージは表示されません。 未定義のプラグマは単に無視されます。

REPLACE

REPLACE コマンドは INSERT コマンドの仲間である "INSERT OR REPLACE" の別名です。これは MySQL との互換性のために提供 されています。詳細は INSERT コマンドの説明を ご覧下さい。

SELECT

SELECT ステートメントはデータベースの問い合わせを行います。SELECT の結果は ０個以上の行からなり、それぞれの行は一定の個数のカラムで構成されます。 結果セット中のカラム数は SELECT と FROM キーワードの間の評価式の並びにより 指定されます。結果セットには任意の評価式を指定できます。結果セットの評価式に * を指定すると、その１つの評価式は 指定されたすべてのテーブルのすべてのカラムで置き換えられます。評価式でテーブル名 の後に .* を指定すると、その１つの テーブルのすべてのカラムを指定したことになります。

DISTINCT キーワードを指定すると、結果のサブセットである返される行が、 それぞれ異なった値を持つようになります。NULL 値はそれぞれ異なった値とは 見なされません。デフォルトの動作ではすべての行が返されますが、これを キーワード ALL により明示することもできます。

クエリーは FROM キーワードの後に指定された１つ以上のテーブルに対して行われます。 複数のテーブル名がカンマで区切って指定されていた場合、クエリーはそれぞれの テーブルの直積(cross join)に対して行われます。結合の指定については、完全な SQL92 における JOIN の書式を使うこともできます。FROM 句の中には、 任意のテーブル名を使って括弧で括った副問い合わせを書くこともできます。 FROM 句全体を省略することもできます。この場合結果セットは行か式の並びの値から 構成される単一行となります。

WHERE 句を使って、クエリーの実行に関する結果の行数を制限することができます。

GROUP BY 句を使うと、結果セットの中の１つ以上の行を結合し、出力時に１行とする ことができます。これは結果セットの中に集約関数がある場合、特に有用です。 GROUP BY 句の中の評価式には、結果セットに現れる評価式が含まれません。 HAVING 句は WHERE 句と同じように使つことができますが、グルーピングが行われた後で 適用されるところが異なります。HAVING 式は、集約関数についてもその値を参照し、 結果の中には現れません。

ORDER BY 句を使うと、出力行はソートされます。ORDER BY の引数は評価式の並びであり、 これがソート時のキーとして使われます。この評価式は単純な SELECT の結果の一部 を含みませんが、複合 SELECT においてはそれぞれのソート評価式は結果のカラムに 完全に一致していなければなりません。ソート評価式の後にオプションで ASC または DESC を指定することによりソート順を指定できます。

LIMIT 句は結果セットとして返される行数の上限を設定します。 LIMIT に負数をセットすると、上限なしという意味になります。 LIMIT の後ろに、結果セットの先頭からスキップする行数を OFFSET オプションで指定できます。 複合クエリーにおいては LIMIT 句は最後の SELECT ステートメントのみに現れるようにします。 制限値はクエリー全体に対して適用され、 LIMIT に結びついている個々の SELECT ステートメントには適用されません。

複合 SELECT は２つ以上の単純 SELECT が UNION, UNION ALL, INTERSECT, EXCEPT のいずれかの演算子により結合された形式です。複合 SELECT においては、 後続のすべての SELECT で同じ数の結果カラムを指定しなければなりません。 複合 SELECT の最後にひとつの ORDER BY 句を書くことができます。 UNION および UNION ALL 演算子は、 複数の SELECT の結果を右側または左側に対して結合し、 ひとつの大きなテーブルを作ります。 違いは、UNION ではすべての結果行はそれぞれユニークになりますが、 UNION ALL では重複行が現れます。 INTERSECT 演算子は左側と右側の SELECT 結果の交差を取ります。 EXCEPT は左側の SELECT 結果から右側の SELECT 結果を取り去ります。 ３つ以上の SELECT が合わさった場合、 それらは左側から右側に向かってグループ化されます。

UPDATE

UPDATE ステートメントはテーブル中の選択された行について、カラムの値を変更します。 UPDATE におけるそれぞれの代入式は等号の左辺にカラム名、右辺に任意の評価式を指定します。 評価式には別のカラムの値が現れても構いません。 評価式はすべて代入が行われる前に評価されます。 WHERE 句を使って UPDATE 対象の行を制限することができます。

オプションの CONFLICT 句を指定して、この一つのコマンドの実行時における 制約違反発生時における代替の解決アルゴリズムを指定することができます。 詳細は ON CONFLICT というタイトルのついたセクションを 参照してください。

VACUUM

VACUUM コマンドは PostgreSQL における同様のコマンドをモデルにした SQLite の拡張機能です。VACUUM がテーブルまたはインデックス名を伴って実行されると、 指定されたテーブルまたはインデックスを整理するものと見なします。 SQLite のバージョン 1.0 では VACUUM コマンドは gdbm_reorganize() を呼び出してバックエンドのデータベースファイルを整理します。

SQLite がバージョン 2.0 になって GDBM バックエンドが除去されたことにより、 VACUUM が何もしないように変更されました。しかしバージョン 2.8.1 で VACUUM は再実装されました。これは現在では一時データベースファイルにデータベースの 内容をコピーし、そのコピーからオリジナルのデータベースを再ロードします。 これにより解放されたページや継続されるアラインテーブルのデータなどが除去され、 データベースファイルの構造が整理されます。インデックスやテーブル名は 現時点では無視されます。

活動中のトランザクションがある場合、このコマンドは実行に失敗します。 このコマンドはメモリ上のデータベースに対しては意味を持ちません。

SQLite キーワード

以下のキーワードは SQLite により使われています。 ほとんどのものは SQL-92 で予約語となっているか、 予約語となり得るものとしてリストアップされていたものです。 これらはイタリック体では表示されません。 すべての単語が実際に SQLite で使われているとは限りません。 SQLite ではキーワードは予約されていません。 どんなキーワードであっても SQLite オブジェクト（カラム、データベース、 インデックス、トリガ、ビューなど）の識別子として使うことができますが、 一般的にはパーサが混乱しないようにブラケットや引用符で括っておかなければ なりません。SQLite におけるキーワードマッチングでは大文字小文字は 区別されません。