他のバージョンの文書 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

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

17.12.1. 以前のPostgreSQLバージョン

add_missing_fromboolean

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

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

regex_flavorstring

正規表現の"種類"は、advancedextendedbasicのいずれかに設定することができます。 デフォルトはadvancedです。 正確に7.4より前のPostgreSQLリリースと後方互換を持たせるためにはextendedが有用です。 詳細は項9.7.3.1を参照してください。

sql_inheritanceboolean

これは継承のセマンティクス、特にデフォルトで各種のコマンドにより副テーブルが含まれるのか否かを管理します。これらはバージョン7.1以前には含まれていませんでした。もし旧いバージョンの動作をさせたい場合はこの変数をoffに設定できますが、副テーブルを排除するONLYキーワードを使用するようにアプリケーションを変更した方が長い目で見ると良いでしょう。継承に関して詳細は項5.8を参照してください。

backslash_quote (string)

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

default_with_oidsboolean

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

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

escape_string_warningboolean

オンの場合、通常の文字列リテラル('...'構文)にバックスラッシュ(\)がない場合、警告が発せられます。

エスケープ文字列構文(E'...')はエスケープのために使用されなければなりません。その理由は、将来のPostgreSQLバージョンにおいて、通常の文字列は(エスケープコードとしての)バックスラッシュを文字通り(バックスラッシュとして)に取り扱う、標準に準拠した振る舞いをするようになるからです。

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

transform_null_equalsboolean

オンの場合、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を参照してください。