Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# 条件
**Topics**
+ [構文](#r_conditions-synopsis)
+ [比較条件](r_comparison_condition.md)
+ [論理条件](r_logical_condition.md)
+ [パターンマッチング条件](pattern-matching-conditions.md)
+ [BETWEEN 範囲条件](r_range_condition.md)
+ [Null 条件](r_null_condition.md)
+ [EXISTS 条件](r_exists_condition.md)
+ [IN 条件](r_in_condition.md)
条件は、評価結果として true、false、または unknown を返す、1 つまたは複数の式および論理演算子から成るステートメントです。条件は述語と呼ばれることもあります。
**注記**
すべての文字列比較および LIKE パターンマッチングでは、大文字と小文字が区別されます。例えば、「A」と「a」は一致しません。ただし、ILIKE 述語を使用すれば、大文字小文字を区別しないパターンマッチングを行うことができます。
## 構文
```
comparison_condition
| logical_condition
| range_condition
| pattern_matching_condition
| null_condition
| EXISTS_condition
| IN_condition
```
# 比較条件
比較条件では、2 つの値の間の論理的な関係を指定します。比較条件はすべて、ブール型の戻り値を返す 2 項演算子です。Amazon Redshift では、次のテーブルで説明する比較演算子をサポートしています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_comparison_condition.html)
## 使用に関する注意事項
= ANY \$1 SOME
ANY と SOME のキーワードは *IN* 条件と同義であり、1 つまたは複数の値を返すサブクエリによって返された少なくとも 1 つの値に対して比較が true である場合に true を返します。Amazon Redshift は、ANY および SOME に対して = (等しい) 条件のみをサポートします。不等条件はサポートされていません。
ALL 述語はサポートされていません。
<> ALL
ALL キーワードは NOT IN ([IN 条件](r_in_condition.md) 条件を参照) と同義であり、サブクエリの結果に式が含まれていない場合に true を返します。Amazon Redshift は、ALL に対して <> または \$1= (等しくない) 条件のみをサポートします。他の比較条件はサポートされていません。
IS TRUE/FALSE/UNKNOWN
ゼロ以外の値は TRUE と等しく、0 は FALSE に等しく、Null は UNKNOWN に等しくなります。「[ブール型HLLSKETCH タイプ](r_Boolean_type.md)」データ型を参照してください。
## 例
ここで、比較条件の簡単な例をいくつか示します。
```
a = 5
a < b
min(x) >= 5
qtysold = any (select qtysold from sales where dateid = 1882
```
次のクエリは、VENUE テーブルから席数が 10000 席を超える会場を返します。
```
select venueid, venuename, venueseats from venue
where venueseats > 10000
order by venueseats desc;
venueid | venuename | venueseats
---------+--------------------------------+------------
83 | FedExField | 91704
6 | New York Giants Stadium | 80242
79 | Arrowhead Stadium | 79451
78 | INVESCO Field | 76125
69 | Dolphin Stadium | 74916
67 | Ralph Wilson Stadium | 73967
76 | Jacksonville Municipal Stadium | 73800
89 | Bank of America Stadium | 73298
72 | Cleveland Browns Stadium | 73200
86 | Lambeau Field | 72922
...
(57 rows)
```
この例では、USERS テーブルからロックミュージックが好きなユーザー (USERID) を選択します。
```
select userid from users where likerock = 't' order by 1 limit 5;
userid
--------
3
5
6
13
16
(5 rows)
```
この例では、USERS テーブルから、ロックミュージックを好きかどうか不明であるユーザー (USERID) を選択します。
```
select firstname, lastname, likerock
from users
where likerock is unknown
order by userid limit 10;
firstname | lastname | likerock
----------+----------+----------
Rafael | Taylor |
Vladimir | Humphrey |
Barry | Roy |
Tamekah | Juarez |
Mufutau | Watkins |
Naida | Calderon |
Anika | Huff |
Bruce | Beck |
Mallory | Farrell |
Scarlett | Mayer |
(10 rows
```
## TIME 列の例
次のテーブルの TIME\$1TEST の例には、3 つの値が挿入された列 TIME\$1VAL (タイプ TIME) があります。
```
select time_val from time_test;
time_val
---------------------
20:00:00
00:00:00.5550
00:58:00
```
次の例では、各 timetz\$1val から時間を抽出します。
```
select time_val from time_test where time_val < '3:00';
time_val
---------------
00:00:00.5550
00:58:00
```
次の例では、2 つの時刻リテラルを比較します。
```
select time '18:25:33.123456' = time '18:25:33.123456';
?column?
----------
t
```
## TIMETZ 列の例
次のテーブルの TIMETZ\$1TEST の例には、3 つの値が挿入された列 TIMETZ\$1VAL (タイプ TIMETZ) があります。
```
select timetz_val from timetz_test;
timetz_val
------------------
04:00:00+00
00:00:00.5550+00
05:58:00+00
```
次の例では、`3:00:00 UTC` 未満の TIMETZ 値のみを選択します。値を UTC に変換した後に比較が行われます。
```
select timetz_val from timetz_test where timetz_val < '3:00:00 UTC';
timetz_val
---------------
00:00:00.5550+00
```
次の例では、2 つの TIMETZ リテラルを比較します。タイムゾーンは、比較のために無視されます。
```
select time '18:25:33.123456 PST' < time '19:25:33.123456 EST';
?column?
----------
t
```
# 論理条件
論理条件は、2 つの条件の結果を結合して 1 つの結果を作成します。論理条件はすべて、ブール型の戻り値を返す 2 項演算子です。
## 構文
```
expression
{ AND | OR }
expression
NOT expression
```
論理条件では 3 値ブール論理を使用します。この場合、Null 値は unknown 関係を表現します。次の表で論理条件の結果について説明します。ここで、`E1` と `E2` は式を表します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_logical_condition.html)
NOT 演算子は AND 演算子より先に評価され、AND 演算子は OR 演算子より先に評価されます。括弧が使用されている場合、評価のデフォルトの順序より優先されます。
### 例
次の例では、USERS テーブルから、ラスベガスもスポーツも好きであるユーザーの USERID および USERNAME を返します。
```
select userid, username from users
where likevegas = 1 and likesports = 1
order by userid;
userid | username
--------+----------
1 | JSG99FHE
67 | TWU10MZT
87 | DUF19VXU
92 | HYP36WEQ
109 | FPL38HZK
120 | DMJ24GUZ
123 | QZR22XGQ
130 | ZQC82ALK
133 | LBN45WCH
144 | UCX04JKN
165 | TEY68OEB
169 | AYQ83HGO
184 | TVX65AZX
...
(2128 rows)
```
次の例では、USERS テーブルから、ラスベガスが好き、スポーツが好き、または両方が好きのいずれかに該当するユーザーの USERID と USERNAME を返します。このクエリでは、前の例の出力と、ラスベガスのみ好き、またはスポーツのみ好きなユーザーとをすべて返します。
```
select userid, username from users
where likevegas = 1 or likesports = 1
order by userid;
userid | username
--------+----------
1 | JSG99FHE
2 | PGL08LJI
3 | IFT66TXU
5 | AEB55QTM
6 | NDQ15VBM
9 | MSD36KVR
10 | WKW41AIW
13 | QTF33MCG
15 | OWU78MTR
16 | ZMG93CDD
22 | RHT62AGI
27 | KOY02CVE
29 | HUH27PKK
...
(18968 rows)
```
次のクエリでは、`OR` 条件を囲む括弧を使用して、マクベスが上演されたニューヨークあるいはカリフォルニアの劇場を探します。
```
select distinct venuename, venuecity
from venue join event on venue.venueid=event.venueid
where (venuestate = 'NY' or venuestate = 'CA') and eventname='Macbeth'
order by 2,1;
venuename | venuecity
----------------------------------------+---------------
Geffen Playhouse | Los Angeles
Greek Theatre | Los Angeles
Royce Hall | Los Angeles
American Airlines Theatre | New York City
August Wilson Theatre | New York City
Belasco Theatre | New York City
Bernard B. Jacobs Theatre | New York City
...
```
この例の括弧を削除すると、クエリの論理および結果が変更されます。
次の例では、`NOT` 演算子を使用します。
```
select * from category
where not catid=1
order by 1;
catid | catgroup | catname | catdesc
-------+----------+-----------+--------------------------------------------
2 | Sports | NHL | National Hockey League
3 | Sports | NFL | National Football League
4 | Sports | NBA | National Basketball Association
5 | Sports | MLS | Major League Soccer
...
```
次の例では、`NOT` 条件の後に `AND` 条件を使用しています。
```
select * from category
where (not catid=1) and catgroup='Sports'
order by catid;
catid | catgroup | catname | catdesc
-------+----------+---------+---------------------------------
2 | Sports | NHL | National Hockey League
3 | Sports | NFL | National Football League
4 | Sports | NBA | National Basketball Association
5 | Sports | MLS | Major League Soccer
(4 rows)
```
# パターンマッチング条件
**Topics**
+ [LIKE](r_patternmatching_condition_like.md)
+ [SIMILAR TO](pattern-matching-conditions-similar-to.md)
+ [POSIX 演算子](pattern-matching-conditions-posix.md)
パターンマッチング演算子は、条件式で指定されたパターンが存在するかどうか文字列を調べ、該当するパターンが見つかったかどうかに応じて true または false を返します。Amazon Redshift は、パターン一致に 3 つの方法を使用します。
+ LIKE 式
LIKE 演算子は、列名などの文字列式を、ワイルドカード文字 `%` (パーセント) および `_` (アンダースコア) を使用したパターンと比較します。LIKE パターンマッチングは常に文字列全体を網羅します。LIKE は大文字小文字を区別するマッチングを実行し、ILIKE は大文字小文字を区別しないマッチングを実行します。
+ SIMILAR TO 正規表現
SIMILAR TO 演算子は、文字列式を、SQL の標準的な正規表現パターンと突き合わせます。このパターンには、LIKE 演算子でサポートされている 2 つを含む一連のパターンマッチングメタ文字を含めることができます。SIMILAR TO は、文字列全体をマッチングし、大文字小文字を区別するマッチングを実行します。
+ POSIX スタイルの正規表現
POSIX 正規表現は、LIKE および SIMILAR TO の演算子の場合よりも強力なパターンマッチング手段を提供します。POSIX 正規表現パターンでは、文字列の任意の部分をマッチングすることができ、大文字小文字を区別するマッチングを実行します。
SIMILAR TO または POSIX の演算子を使用する正規表現マッチングは、計算コストが高くなります。非常に多くの行を処理する場合は特に、可能な限り、LIKE を使用することをお勧めします。例えば、以下に示す各クエリは機能的には同じですが、LIKE を使用したクエリは、正規表現を使用したクエリよりも数倍速く実行できます。
```
select count(*) from event where eventname SIMILAR TO '%(Ring|Die)%';
select count(*) from event where eventname LIKE '%Ring%' OR eventname LIKE '%Die%';
```
# LIKE
LIKE 演算子は、列名などの文字列式を、ワイルドカード文字 % (パーセント) および \$1 (アンダースコア) を使用したパターンと比較します。LIKE パターンマッチングは常に文字列全体を網羅します。文字列内の任意の場所にあるシーケンスをマッチングするには、パターンがパーセント符号で始まりパーセント符号で終了する必要があります。
LIKE は大文字小文字を区別し、ILIKE は大文字小文字を区別しません。
## 構文
```
expression [ NOT ] LIKE | ILIKE pattern [ ESCAPE 'escape_char' ]
```
## 引数
*expression*
列名など、有効な UTF-8 文字式。
LIKE \$1 ILIKE
LIKE は大文字小文字を区別するパターンマッチングを実行します。ILIKE は、シングルバイト UTF-8 (ASCII) 文字に対して大文字小文字を区別しないパターンマッチングを実行します。マルチバイト文字に対して大文字と小文字を区別しないパターンの一致を実行するには、LIKE 条件の *pattern* と *pattern* で [LOWER](r_LOWER.md) 関数を使用します。
= や <> などの比較述語とは対照的に、述語 LIKE と ILIKE は、末尾の空白を暗黙的に無視しません。末尾のスペースを無視するには、RTRIM を使用するか、または CHAR 列を VARCHAR に明示的にキャストします。
`~~` 演算子は LIKE に相当し、`~~*` は ILIKE に相当します。また、`!~~` および `!~~*` 演算子は、NOT LIKE および NOT ILIKE に相当します。
*pattern*
マッチングするパターンが含まれる有効な UTF-8 文字式。
*escape\$1char*
パターン内でメタ文字をエスケープする文字式。デフォルトは 2 個のバックスラッシュ (「\$1\$1」) です。
*pattern* にメタ文字が含まれていない場合、pattern は文字列そのものを表現するにすぎません。その場合、LIKE は等号演算子と同じ働きをします。
どちらの文字式も CHAR または VARCHAR のデータ型になることができます。文字式の型が異なる場合、Amazon Redshift は *pattern* のデータ型を *expression* のデータ型に変換します。
LIKE では、次のパターンマッチングメタ文字をサポートしています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_patternmatching_condition_like.html)
## 例
次の例では、LIKE を使用したパターンマッチングの例を示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_patternmatching_condition_like.html)
次の例では、名前が「E」で始まるすべての市を見つけます。
```
select distinct city from users
where city like 'E%' order by city;
city
---------------
East Hartford
East Lansing
East Rutherford
East St. Louis
Easthampton
Easton
Eatontown
Eau Claire
...
```
次の例では、姓に「ten」が含まれるユーザーを見つけます。
```
select distinct lastname from users
where lastname like '%ten%' order by lastname;
lastname
-------------
Christensen
Wooten
...
```
次の例は、複数のパターンを一致させる方法を示しています。
```
select distinct lastname from tickit.users
where lastname like 'Chris%' or lastname like '%Wooten' order by lastname;
lastname
-------------
Christensen
Christian
Wooten
...
```
次の例では、3 番目と 4 番目の文字が「ea」になっている市を見つけます。コマンドでは ILIKE を使用して、大文字小文字の区別なしを実演します。
```
select distinct city from users where city ilike '__EA%' order by city;
city
-------------
Brea
Clearwater
Great Falls
Ocean City
Olean
Wheaton
(6 rows)
```
次の例では、デフォルトのエスケープ文字列 (\$1\$1) を使用して「start\$1」を含む文字列を検索します (テキスト `start`、それに続いてアンダースコア `_`)。
```
select tablename, "column" from pg_table_def
where "column" like '%start\\_%'
limit 5;
tablename | column
-------------------+---------------
stl_s3client | start_time
stl_tr_conflict | xact_start_ts
stl_undone | undo_start_ts
stl_unload_log | start_time
stl_vacuum_detail | start_row
(5 rows)
```
次の例では、エスケープ文字として '^' を指定し、そのエスケープ文字を使用して「start\$1」を含む文字列を検索します (テキスト `start`、それに続いてアンダースコア `_`)。
```
select tablename, "column" from pg_table_def
where "column" like '%start^_%' escape '^'
limit 5;
tablename | column
-------------------+---------------
stl_s3client | start_time
stl_tr_conflict | xact_start_ts
stl_undone | undo_start_ts
stl_unload_log | start_time
stl_vacuum_detail | start_row
(5 rows)
```
次の例では、`~~*` 演算子を使用して「Ag」で始まる都市の大文字と小文字を区別しない (ILIKE) 検索を行います。
```
select distinct city from users where city ~~* 'Ag%' order by city;
city
------------
Agat
Agawam
Agoura Hills
Aguadilla
```
# SIMILAR TO
SIMILAR TO 演算子は、列名などの文字列式を、SQL の標準的な正規表現パターンと突き合わせます。SQL の正規表現パターンには、[LIKE](r_patternmatching_condition_like.md) 演算子によってサポートされる 2 つを含む、一連のパターンマッチングメタ文字を含めることができます。
SIMILAR TO 演算子の場合は、POSIX の正規表現の動作 (パターンは文字列の任意の部分と一致できる) とは異なり、パターンが文字全体と一致した場合にのみ true を返します。
SIMILAR TO は大文字小文字を区別するマッチングを実行します。
**注記**
SIMILAR TO を使用する正規表現マッチングは、計算コストが高くなります。非常に多くの行を処理する場合は特に、可能な限り、LIKE を使用することをお勧めします。例えば、以下に示す各クエリは機能的には同じですが、LIKE を使用したクエリは、正規表現を使用したクエリよりも数倍速く実行できます。
```
select count(*) from event where eventname SIMILAR TO '%(Ring|Die)%';
select count(*) from event where eventname LIKE '%Ring%' OR eventname LIKE '%Die%';
```
## 構文
```
expression [ NOT ] SIMILAR TO pattern [ ESCAPE 'escape_char' ]
```
## 引数
*expression*
列名など、有効な UTF-8 文字式。
SIMILAR TO
SIMILAR TO は、*expression* 内の文字列全体について、大文字小文字を区別するパターンマッチングを実行します。
* パターン*
SQL の標準的な正規表現パターンを表現する有効な UTF-8 文字式。
*escape\$1char*
パターン内でメタ文字をエスケープする文字式。デフォルトは 2 個のバックスラッシュ (「\$1\$1」) です。
*pattern* にメタ文字が含まれていない場合、pattern は文字列そのものを表現するにすぎません。
どちらの文字式も CHAR または VARCHAR のデータ型になることができます。文字式の型が異なる場合、Amazon Redshift は *pattern* のデータ型を *expression* のデータ型に変換します。
SIMILAR TO では、次のパターンマッチングメタ文字をサポートしています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/pattern-matching-conditions-similar-to.html)
## 例
次の表に、SIMILAR TO を使用したパターンマッチングの例を示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/pattern-matching-conditions-similar-to.html)
次の例では、名前に「E」または「H」が含まれる市を見つけます。
```
SELECT DISTINCT city FROM users
WHERE city SIMILAR TO '%E%|%H%' ORDER BY city LIMIT 5;
city
-----------------
Agoura Hills
Auburn Hills
Benton Harbor
Beverly Hills
Chicago Heights
```
次の例では、デフォルトのエスケープ文字列 ('`\\`') を使用して「`_`」を含む文字列を検索します。
```
SELECT tablename, "column" FROM pg_table_def
WHERE "column" SIMILAR TO '%start\\_%'
ORDER BY tablename, "column" LIMIT 5;
tablename | column
--------------------------+---------------------
stcs_abort_idle | idle_start_time
stcs_abort_idle | txn_start_time
stcs_analyze_compression | start_time
stcs_auto_worker_levels | start_level
stcs_auto_worker_levels | start_wlm_occupancy
```
次の例では、エスケープ文字列として '`^`' を指定し、エスケープ文字列を使用して「`_`」を含む文字列を検索します。
```
SELECT tablename, "column" FROM pg_table_def
WHERE "column" SIMILAR TO '%start^_%' ESCAPE '^'
ORDER BY tablename, "column" LIMIT 5;
tablename | column
--------------------------+---------------------
stcs_abort_idle | idle_start_time
stcs_abort_idle | txn_start_time
stcs_analyze_compression | start_time
stcs_auto_worker_levels | start_level
stcs_auto_worker_levels | start_wlm_occupancy
```
# POSIX 演算子
POSIX 正規表現は、マッチパターンを指定する一連の文字です。文字列が正規表現で記述された正規セットのメンバーであれば、その文字列は正規表現と一致します。
POSIX 正規表現は、[LIKE](r_patternmatching_condition_like.md) および [SIMILAR TO](pattern-matching-conditions-similar-to.md) の演算子の場合よりも強力なパターンマッチング手段を提供します。POSIX 正規表現のパターンは、パターンが文字列全体と一致した場合にのみ true を返す SIMILAR TO 演算子の場合とは異なり、文字列の任意の部分と一致することができます。
**注記**
POSIX 演算子を使用する正規表現マッチングは、計算コストが高くなります。非常に多くの行を処理する場合は特に、可能な限り、LIKE を使用することをお勧めします。例えば、以下に示す各クエリは機能的には同じですが、LIKE を使用したクエリは、正規表現を使用したクエリよりも数倍速く実行できます。
```
select count(*) from event where eventname ~ '.*(Ring|Die).*';
select count(*) from event where eventname LIKE '%Ring%' OR eventname LIKE '%Die%';
```
## 構文
```
expression [ ! ] ~ pattern
```
## 引数
*expression*
列名など、有効な UTF-8 文字式。
\$1
拒否演算子。正規表現パターンに一致しません。
\$1
*式*の部分文字列に対して大文字/小文字を区別するマッチングを実行します。
`~~` は [LIKE](r_patternmatching_condition_like.md) の同義語です。
* パターン*
正規表現パターンを表す文字列リテラル。
*pattern* にワイルドカード文字が含まれていない場合、pattern は文字列そのものを表現するにすぎません。
'`. * | ? `' などのメタ文字を含む文字列を検索するには、2 つのバックスラッシュ ('` \\`') を使用して文字をエスケープします。`SIMILAR TO` や `LIKE` と異なり、POSIX 正規表現の構文はユーザー定義のエスケープ文字をサポートしていません。
どちらの文字式も CHAR または VARCHAR のデータ型になることができます。文字式の型が異なる場合、Amazon Redshift は *pattern* のデータ型を *expression* のデータ型に変換します。
文字式はすべて CHAR または VARCHAR のデータ型にすることができます。文字式のデータ型が異なる場合、Amazon Redshift はそれらのデータ型を *expression* のデータ型に変換します。
POSIX パターンマッチングでは、以下のメタ文字がサポートされています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/pattern-matching-conditions-posix.html)
Amazon Redshift では、以下の POSIX 文字クラスがサポートされています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/pattern-matching-conditions-posix.html)
Amazon Redshift では、Perl の影響を受けた以下の演算子が正規表現でサポートされています。2 つのバックスラッシュ (「`\\`」) を使用して演算子をエスケープします。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/pattern-matching-conditions-posix.html)
## 例
次の表に、POSIX 演算子を使用したパターンマッチングの例を示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/pattern-matching-conditions-posix.html)
以下の例では、名前に `E` または `H` が含まれる市を見つけます。
```
SELECT DISTINCT city FROM users
WHERE city ~ '.*E.*|.*H.*' ORDER BY city LIMIT 5;
city
-----------------
Agoura Hills
Auburn Hills
Benton Harbor
Beverly Hills
Chicago Heights
```
以下の例では、名前に `E` または `H` が含まれない市を見つけます。
```
SELECT DISTINCT city FROM users WHERE city !~ '.*E.*|.*H.*' ORDER BY city LIMIT 5;
city
-----------------
Aberdeen
Abilene
Ada
Agat
Agawam
```
以下の例では、エスケープ文字列 ('`\\`') を使用してピリオドを含む文字列を検索します。
```
SELECT venuename FROM venue
WHERE venuename ~ '.*\\..*'
ORDER BY venueid;
venuename
------------------------------
St. Pete Times Forum
Jobing.com Arena
Hubert H. Humphrey Metrodome
U.S. Cellular Field
Superpages.com Center
E.J. Nutter Center
Bernard B. Jacobs Theatre
St. James Theatre
```
# BETWEEN 範囲条件
`BETWEEN` 条件では、キーワード `BETWEEN` および `AND` を使用して、値が範囲内に入っているかどうか式をテストします。
## 構文
```
expression [ NOT ] BETWEEN expression AND expression
```
式は、数値データ型、文字データ型、または日時データ型とすることができますが、互換性を持つ必要があります。範囲は両端を含みます。
## 例
最初の例では、2、3、または 4 のいずれかのチケットの販売を登録したトランザクション数をカウントします。
```
select count(*) from sales
where qtysold between 2 and 4;
count
--------
104021
(1 row)
```
範囲条件は開始値と終了値を含みます。
```
select min(dateid), max(dateid) from sales
where dateid between 1900 and 1910;
min | max
-----+-----
1900 | 1910
```
範囲条件内の最初の式は最小値、2 番目の式は最大値である必要があります。次の例は、式の値のせいで、常にゼロ行を返します。
```
select count(*) from sales
where qtysold between 4 and 2;
count
-------
0
(1 row)
```
しかし、NOT 修飾子を加えると、論理が反転し、すべての行がカウントされます。
```
select count(*) from sales
where qtysold not between 4 and 2;
count
--------
172456
(1 row)
```
次のクエリは、20000～50000 席を備えた会場のリストを返します。
```
select venueid, venuename, venueseats from venue
where venueseats between 20000 and 50000
order by venueseats desc;
venueid | venuename | venueseats
---------+-------------------------------+------------
116 | Busch Stadium | 49660
106 | Rangers BallPark in Arlington | 49115
96 | Oriole Park at Camden Yards | 48876
...
(22 rows)
```
次の例は、日付値に BETWEEN を使用する方法を示しています。
```
select salesid, qtysold, pricepaid, commission, saletime
from sales
where eventid between 1000 and 2000
and saletime between '2008-01-01' and '2008-01-03'
order by saletime asc;
salesid | qtysold | pricepaid | commission | saletime
--------+---------+-----------+------------+---------------
65082 | 4 | 472 | 70.8 | 1/1/2008 06:06
110917 | 1 | 337 | 50.55 | 1/1/2008 07:05
112103 | 1 | 241 | 36.15 | 1/2/2008 03:15
137882 | 3 | 1473 | 220.95 | 1/2/2008 05:18
40331 | 2 | 58 | 8.7 | 1/2/2008 05:57
110918 | 3 | 1011 | 151.65 | 1/2/2008 07:17
96274 | 1 | 104 | 15.6 | 1/2/2008 07:18
150499 | 3 | 135 | 20.25 | 1/2/2008 07:20
68413 | 2 | 158 | 23.7 | 1/2/2008 08:12
```
BETWEEN の範囲は包括的ですが、日付はデフォルトで 00:00:00 の時刻値であることに注意してください。サンプルクエリで有効な 1 月 3 日の行は、販売時間が `1/3/2008 00:00:00` の行だけです。
# Null 条件
Null 条件は、値が見つからないか、値が不明であるときに、Null かどうかテストします。
## 構文
```
expression IS [ NOT ] NULL
```
## 引数
*expression*
列のような任意の式。
IS NULL
式の値が Null の場合は true で、式が値を持つ場合は false です。
IS NOT NULL
式の値が Null の場合は false で、式が値を持つ場合は true です。
## 例
この例では、SALES テーブルの QTYSOLD フィールドで Null が何回検出されるかを示します。
```
select count(*) from sales
where qtysold is null;
count
-------
0
(1 row)
```
# EXISTS 条件
EXISTS 条件は、サブクエリ内に行が存在するかどうかをテストし、サブクエリが少なくとも 1 つの行を返した場合に true を返します。NOT が指定されると、条件はサブクエリが行を返さなかった場合に true を返します。
## 構文
```
[ NOT ] EXISTS (table_subquery)
```
## 引数
EXISTS
*table\$1subquery* が少なくとも 1 つの行を返した場合に true となります。
NOT EXISTS
*table\$1subquery* が行を返さない場合に true になります。
*table\$1subquery*
評価結果として 1 つまたは複数の列と 1 つまたは複数の行を持つテーブルを返します。
## 例
この例では、任意の種類の販売があった日付ごとに、1 回ずつ、すべての日付識別子を返します。
```
select dateid from date
where exists (
select 1 from sales
where date.dateid = sales.dateid
)
order by dateid;
dateid
--------
1827
1828
1829
...
```
# IN 条件
IN 条件は、一連の値の中に、またはサブクエリ内にあるメンバーシップの値をテストします。
## 構文
```
expression [ NOT ] IN (expr_list | table_subquery)
```
## 引数
*expression*
*expr\$1list* または *table\$1subquery* に対して評価される数値、文字、または日時であり、当該リストまたはサブクエリのデータ型との互換性が必要です。
*expr\$1list*
1 つまたは複数のカンマ区切り式、あるいは括弧で囲まれたカンマ区切り式の 1 つまたは複数のセット。
*table\$1subquery*
評価結果として 1 つまたは複数の行を持つテーブルを返すサブクエリですが、その選択リスト内の列数は 1 個に制限されています。
IN \$1 NOT IN
IN は、式が式リストまたはクエリのメンバーである場合に true を返します。NOT IN は、式がメンバーでない場合に true を返します。*expression* の結果が Null である場合、または、一致する *expr\$1list* 値または *table\$1subquery* 値がなく、これらの比較行の 1 つ以上の結果が Null である場合、IN と NOT IN は NULL を返し、行は返されません。
## 例
次の条件は、リストされた値の場合にのみ true を返します。
```
qtysold in (2, 4, 5)
date.day in ('Mon', 'Tues')
date.month not in ('Oct', 'Nov', 'Dec')
```
## 大規模 IN リストの最適化
クエリのパフォーマンスを最適化するために、10 個を超える値が含まれる IN リストは内部的にスカラー配列として評価されます。10 個未満の値が含まれる IN リストは一連の OR 述語として評価されます。SMALLINT、INTEGER、BIGINT、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ データ型では最適化がサポートされています。
この最適化の効果を確認するには、クエリの EXPLAIN 出力を調べてください。次に例を示します。
```
explain select * from sales
QUERY PLAN
--------------------------------------------------------------------
XN Seq Scan on sales (cost=0.00..6035.96 rows=86228 width=53)
Filter: (salesid = ANY ('{1,2,3,4,5,6,7,8,9,10,11}'::integer[]))
(2 rows)
```