バージョンとプラットフォーム互換性

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 18章サーバの構成 | 早送り | 次のページ

# 18.12. バージョンとプラットフォーム互換性

## 18.12.1. 以前のPostgreSQLバージョン

`add_missing_from`（`論理値`）

  オンの場合、問い合わせによって参照されるテーブルは、既に存在していなければ`FROM`句に追加されます。この動作はSQL標準に準拠しておらず、多くのユーザは（そのエイリアスを参照しなければならないテーブル参照をする場合など）誤りを隠蔽するため、嫌がります。デフォルトは`off`です。この変数は、この動作がデフォルトで認められている8.1以前のPostgreSQLリリースとの互換性を有効にします。

  この変数が有効になっているとしても、問い合わせによって参照される個々の明示的`FROM`エントリに対し、警告メッセージが放出されることに注意してください。問い合わせの`FROM`句に対する問い合わせで参照される全てのテーブルを追加すること（もしくは`DELETE`の場合のその`USING`句）に依る、この動作に信頼を置かないアプリケーションの更新に、ユーザは消極的になります。

`array_nulls` (`論理値`)

  これは、配列入力パーサが引用符のない`NULL`をNULL配列要素として認識するかどうかを制御します。 デフォルトでは、これは`on`で、NULL値を持つ配列値を入力することができます。 しかし、8.2より前のバージョンのPostgreSQLでは、配列内のNULL値をサポートしておらず、`NULL`を"NULL"という値の文字列を持つ通常の配列要素として扱っていました。 古い動作を必要とするアプリケーションの後方互換性のため、この変数を`off`にすることができます。

  この変数が`off`であっても、NULL値を含む配列値を作成することができることに注意してください。

`backslash_quote` (`enum`)

  文字列リテラルの中で引用符が`\'`で表現されるかどうかを管理します。引用符の表現としてSQL準拠の方式では二重化（`''`）ですが、PostgreSQLは歴史的に`\'`も受け付けます。とは言っても、いくつかのクライアント文字集合符号化方式において、最終バイトが数値的にASCIIの`\`に等しいマルチバイト文字があり、`\'`を使用するとセキュリティ上問題を引き起こす可能性があります。クライアント側のコードが事実上エスケープを正しく扱わない場合、SQLインジェクション攻撃が可能になります。この危険性の回避は、サーバが逆スラッシュでエスケープされた引用符を含む問い合わせを拒絶するようにします。許可される`backslash_quote`の値は、`on` （常に `\'` を許可）, `off` （常に拒否）、および `safe_encoding` （クライアント符号化方式がASCIIの`\`を許可しないときのみ、マルチバイト文字内で許可）。 `safe_encoding` がデフォルトの設定。

  標準に従った文字列リテラルでは、`\`は単に`\`を意味するものです。 このパラメータは、エスケープ文字列構文（`E'...'`）を含む標準に従わないリテラルの取り扱いに影響します。

`default_with_oids`（`論理値`）

  もし`WITH OIDS`もしくは`WITHOUT OIDS`のいずれも指定されていない場合、`CREATE TABLE`および`CREATE TABLE AS`がオブジェクト識別子（OID）列を新規作成のテーブルに含めるか否かを管理します。 同時に`SELECT INTO`で作成されたテーブルにOIDが含まれるか否かも決定します。 PostgreSQL 8.1の`default_with_oids`は、デフォルトで`off`です。 以前のバージョンのPostgreSQLはデフォルトで有効でした。

  ユーザテーブルでのOID使用は良くないと考えらるため、ほとんどのインストレーションはこの変数を無効にしたままになっています。特定のテーブルに対してOIDを必要とするアプリケーションは、テーブル作成にあたって`WITH OIDS`を指定しなければなりません。この変数は、この動作を行わない古いアプリケーションとの互換性を出来るようにさせます。

`escape_string_warning`（`論理値`）

  有効の場合、通常の文字列リテラル（`'...'`構文）にバックスラッシュ（`\`）があり、`standard_conforming_strings`が無効な場合、、警告が発せられます。 デフォルトは`on`です。

  SQL互換性のために、今後のリリースで通常の文字列のデフォルト動作を変更する予定ですので、バックスラッシュをエスケープとして使用したいアプリケーションは、エスケープ文字列構文(`E'...'`)を使用するように変更すべきです。 この変数を有効にすることで、将来失敗するアプリケーションの検出を補助することができます。

`regex_flavor` (`enum`)

  正規表現の"好み"を`advanced`、`extended`、`basic`のいずれかに設定することができます。 `extended`という設定は、7.4より前のリリースのPostgreSQLとの正確な後方互換性のために有用です。 詳細は項9.7.3.1を参照してください。

`sql_inheritance` (`論理値`)

  これは継承の意味を制御します。 `off`にすると、デフォルトで子テーブルが各種コマンドで含まれなくなります。 基本的には暗黙的な`ONLY`キーワードです。 これは7.1以前のリリースとの互換性のために追加されました。 詳細は項5.8を参照してください。

`standard_conforming_strings` (`boolean`)

  標準SQLで規定されたように、通常の文字列リテラル（`'...'`）がバックスラッシュをそのまま取り扱うか否かを制御します。 この値は現在常に、バックスラッシュはエスケープとして取り扱われることを意味する、`off`になっています。 これは将来、PostgreSQLのリリースで標準との互換性を向上するために、`on`に変更される予定です。 どのように文字列リテラルが処理されるかを決めるこのパラメータを、アプリケーションで検査することができます。 このパラメータの存在は、エスケープ文字列構文（`E'...'`）がサポートされているかどうかを示すものとも考えられます。 エスケープ文字列構文は、アプリケーションでバックスラッシュをエスケープ文字として扱いたい場合に使用すべきです。

`synchronize_seqscans` (`論理値`)

  これにより、同時実行スキャンがほぼ同じ時間に同じブロックを読み取り、I/Oへの負荷を分散できるように、互いに同期して、大規模テーブルをシーケンシャルスキャンすることができます。 これが有効な場合、スキャンはテーブルの途中から始まり、進行中のスキャンの活動と同期するように、行全体を覆うように終端を"巻き上げる"可能性があります。 これにより、`ORDER BY`句を持たない問い合わせが返す行の順序は予想できない程変わってしまいます。 このパラメータを`off`にすることで、シーケンシャルスキャンが常にテーブルの先頭から始まるという、8.3より前の動作を保証します。 デフォルトは`on`です。

## 18.12.2. プラットホームとクライアント互換性

`transform_null_equals`（`論理値`）

  有効の場合、``expr` = NULL`（もしくは`NULL = `expr``）形式の式は``expr` IS NULL`として取り扱われ、それは、もし`expr`がNULL値と評価すれば真を返し、そうでなければ偽を返します。 ``expr` = NULL`の正しいSQL仕様準拠の動作は常にNULL（判らない）を返すことです。 ですから、このパラメータのデフォルトは`off`になっています。

  しかし、Microsoft Accessのフィルタ形式はNULL値を検査するために``expr` = NULL`を使用する問い合わせを生成しますので、そのインタフェースを使用してデータベースにアクセスする場合は、このオプションを有効にする方が良いでしょう。 ``expr` = NULL`という形の式は（正しい解釈を使用した結果）常にNULL値を返しますので、通常のアプリケーションでは意味がほとんどなく、滅多に使用されません。 ですので、このオプションは実際は害はありません。 しかし、慣れていないユーザはしばしばNULL値に関する式の意味に戸惑いますので、デフォルトでこのオプションは有効になっていません。

  このオプションは`= NULL`という形式にのみ影響することに注意してください。 他の比較演算子や等価演算子を呼び出す他の（`IN`のような）式と計算する上で等価となる式には影響を与えません。 したがって、このオプションは間違ったプログラミングの汎用的な問題解決を行いません。

  関連する情報は項9.2を参照してください。

前のページ | ホーム | 次のページ
ロック管理 | 上に戻る | 設定済みのオプション