これは、配列入力パーサが引用符のない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'...'）を含む標準に従わないリテラルの取り扱いに影響します。

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

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

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

この変数を設定しても、ラージオブジェクトに関連した全ての安全性チェックを無効にする訳ではありません。 PostgreSQL 9.0で変更されたデフォルトの動きに対してのみです。

onの場合、演算子の優先順位の変更の結果、PostgreSQL 9.4以降で意味が変わる可能性のある構文に対して、パーサは警告を出力します。 これは、優先順位の変更によりアプリケーションに何か不具合が起きないか監視するのに役立ちます。 しかし、これはプロダクション環境でオンにしたままにしておくためのものではありません。 なぜなら、完全に正しいSQL標準準拠コードに対しても警告を発するからです。 デフォルトはoffです。

詳細は4.1.6を見てください。

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

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

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

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