オンの場合、問い合わせによって参照されるテーブルは、既に存在していなければFROM句に追加されます。この振る舞いはSQL標準に準拠しておらず、多くのユーザは（そのエイリアスを参照しなければならないテーブル参照をする場合など）誤りを隠蔽するため、嫌がります。デフォルトはoffです。この変数は、この振る舞いがデフォルトで認められている8.1以前のPostgreSQLリリースとの互換性を有効にします。
この変数が有効になっているとしても、問い合わせによって参照される個々の明示的FROMエントリに対し、警告メッセージが放出されることに注意してください。問い合わせのFROM句に対する問い合わせで参照される全てのテーブルを追加すること（もしくはDELETEの場合のそのUSING句）に依る、この振る舞いに信頼を置かないアプリケーションの更新に、ユーザは消極的になります。
これは、配列入力パーサが引用符のないNULLをNULL配列要素として認識するかどうかを制御します。 デフォルトでは、これはonで、NULL値を持つ配列値を入力することができます。 しかし、8.2より前のバージョンのPostgreSQLでは、配列内のNULL値をサポートしておらず、NULLを"NULL"という値の文字列を持つ通常の配列要素として扱っていました。 古い動作を必要とするアプリケーションの後方互換性のため、この変数をoffにすることができます。
この変数がoffであっても、NULL値を含む配列値を作成することができることに注意してください。
文字列リテラルの中で引用符が\'で表現されるかどうかを管理します。引用符の表現としてSQL準拠の方式では二重化（''）ですが、PostgreSQLは歴史的に\'も受け付けます。とは言っても、いくつかのクライアント文字集合符号化方式において、最終バイトが数値的にASCIIの\に等しいマルチバイト文字があり、\'を使用するとセキュリティ上問題を引き起こす可能性があります。クライアント側のコードが事実上エスケープを正しく扱わない場合、SQLインジェクション攻撃が可能になります。この危険性の回避は、サーバが逆スラッシュでエスケープされた引用符を含む問い合わせを拒絶するようにします。許可されるbackslash_quoteの値は、 on （常に \' を許可）, off （常に拒否）、および safe_encoding （クライアント符号化方式がASCIIの\を許可しないときのみ、マルチバイト文字内で許可）。 safe_encoding がデフォルトの設定。
標準に従った文字列リテラルでは、\は単に\を意味するものです。 このパラメータは、エスケープ文字列構文（E'...'）を含む標準に従わないリテラルの取り扱いに影響します。
もし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を指定しなければなりません。この変数は、この振る舞いを行わない古いアプリケーションとの互換性を出来るようにさせます。
有効の場合、通常の文字列リテラル（'...'構文）にバックスラッシュ（\）があり、standard_conforming_stringsが無効な場合、、警告が発せられます。 デフォルトはonです。
SQL互換性のために、今後のリリースで通常の文字列のデフォルト動作を変更する予定ですので、バックスラッシュをエスケープとして使用したいアプリケーションは、エスケープ文字列構文(E'...')を使用するように変更すべきです。 この変数を有効にすることで、将来失敗するアプリケーションの検出を補助することができます。
正規表現の"好み"をadvanced、extended、basicのいずれかに設定することができます。 extendedという設定は、7.4より前のリリースのPostgreSQLとの正確な後方互換性のために有用です。 詳細は項9.7.3.1を参照してください。
これは継承の意味を制御します。 offにすると、デフォルトで子テーブルが各種コマンドで含まれなくなります。 基本的には暗黙的なONLYキーワードです。 これは7.1以前のリリースとの互換性のために追加されました。 詳細は項5.8を参照してください。
標準SQLで規定されたように、通常の文字列リテラル（'...'）がバックスラッシュをそのまま取り扱うか否かを制御します。 この値は現在常に、バックスラッシュはエスケープとして取り扱われることを意味する、offになっています。 これは将来、PostgreSQLのリリースで標準との互換性を向上するために、onに変更される予定です。 どのように文字列リテラルが処理されるかを決めるこのパラメータを、アプリケーションで検査しても良いでしょう。 このパラメータの存在は、エスケープ文字列構文（E'...'）がサポートされているかどうかを示すものとも考えられます。 エスケープ文字列構文は、アプリケーションでバックスラッシュをエスケープ文字として扱いたい場合に使用すべきです。
有効の場合、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を参照してください。