他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 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

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

18.13.1. 以前のPostgreSQLバージョン

array_nulls (boolean)

これは、配列入力パーサが引用符のない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 (boolean)

もしWITH OIDSもしくはWITHOUT OIDSのいずれも指定されていない場合、CREATE TABLEおよびCREATE TABLE ASがオブジェクト識別子(OID)列を新規作成のテーブルに含めるか否かを管理します。 同時にSELECT INTOで作成されたテーブルにOIDが含まれるか否かも決定します。 このパラメータはデフォルトでoffです。PostgreSQL 8.0およびそれ以前ではデフォルトでonでした。

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

escape_string_warning (boolean)

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

通常文字列のデフォルトの振る舞いは、SQL標準ではバックスラッシュを通常文字として取り扱うため、バックスラッシュをエスケープとして使用したいアプリケーションは、エスケープ文字列構文(E'...')を使用するように変更すべきです。 この変数は変更すべきコードを突き止めるのに役立つよう、有効にすることができます。

lo_compat_privileges (boolean)

9.0以前のPostgreSQLリリースでは、ラージオブジェクトはアクセス権限が無く、そしてその結果、全てのユーザが読み込み、書き込みが可能でした。 この変数をonにすると、以前のリリースとの互換性のため、新規の権限チェックが無効になります。 デフォルトはoffです。

この変数を設定してもラージオブジェクトに関連した全ての安全性チェックを無効にしません。 PostgreSQL 9.0.で変更されたデフォルトの動きに対してのみです。 例えば、lo_import()lo_export()はこの設定とは別にスーパユーザの権限を必要とします。

quote_all_identifiers (boolean)

データベースがSQLを生成する時、たとえ(現在)キーワードになっていなくても、全ての識別子を引用符で囲むことを強制します。 これは EXPLAINの出力に影響を与えるのみならず、pg_get_viewdefのような関数の結果にも影響します。 pg_dump および pg_dumpall--quote-all-identifiersオプションも参照してください。

sql_inheritance (boolean)

この設定は、修飾されていないテーブル参照が継承された子テーブルを含むものとみなすかどうかを制御します。 デフォルトはonであり、子テーブルが含まれることを意味します(つまりデフォルトでは*が仮定されます)。 offに変更すると、子テーブルは含まれません(つまりONLY接頭辞が仮定されます)。 標準SQLでは、子テーブルが含まれることを要求します。 このためoffという設定は標準互換ではありません。 しかしPostgreSQL 7.1以前のリリースとの互換性のため提供されています。 項5.8を参照してください。

sql_inheritanceを無効にすることは廃止予定です。 この動作は標準SQLと比べてエラーを招きやすいことが分かっているためです。 通常本書で説明する継承に関する動作説明では、onであることを前提としています。

standard_conforming_strings (boolean)

標準SQLで規定されたように、通常の文字列リテラル('...')がバックスラッシュをそのまま取り扱うか否かを制御します。 PostgreSQL 9.1の初期においてデフォルトはonです(それ以前のリリースではデフォルトとしてoffでした)。 どのように文字列リテラルが処理されるかを決めるこのパラメータを、アプリケーションで検査することができます。 このパラメータの存在は、エスケープ文字列構文(E'...')がサポートされているかどうかを示すものとも考えられます。 エスケープ文字列構文 (項4.1.2.2)は、アプリケーションでバックスラッシュをエスケープ文字として扱いたい場合に使用すべきです。

synchronize_seqscans (boolean)

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

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

transform_null_equals (boolean)

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

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

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

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