This controls whether the array input parser recognizes unquoted <literal>NULL</literal> as specifying a null array element. By default, this is <literal>on</literal>, allowing array values containing null values to be entered. However, <productname>PostgreSQL</productname> versions before 8.2 did not support null values in arrays, and therefore would treat <literal>NULL</literal> as specifying a normal array element with the string value <quote>NULL</quote>. For backward compatibility with applications that require the old behavior, this variable can be turned <literal>off</literal>. これは、配列入力パーサが引用符のないNULLをNULL配列要素として認識するかどうかを制御します。 デフォルトでは、これはonで、NULL値を持つ配列値を入力することができます。 しかし、8.2より前のバージョンのPostgreSQLでは、配列内のNULL値をサポートしておらず、NULLを「NULL」という値の文字列を持つ通常の配列要素として扱っていました。 古い動作を必要とするアプリケーションの後方互換性のため、この変数をoffにすることができます。

Note that it is possible to create array values containing null values even when this variable is <literal>off</literal>. この変数がoffであっても、NULL値を含む配列値を作成することができることに注意してください。

This controls whether a quote mark can be represented by <literal>\'</literal> in a string literal. The preferred, SQL-standard way to represent a quote mark is by doubling it (<literal>''</literal>) but <productname>PostgreSQL</productname> has historically also accepted <literal>\'</literal>. However, use of <literal>\'</literal> creates security risks because in some client character set encodings, there are multibyte characters in which the last byte is numerically equivalent to ASCII <literal>\</literal>. If client-side code does escaping incorrectly then an SQL-injection attack is possible. This risk can be prevented by making the server reject queries in which a quote mark appears to be escaped by a backslash. The allowed values of <varname>backslash_quote</varname> are <literal>on</literal> (allow <literal>\'</literal> always), <literal>off</literal> (reject always), and <literal>safe_encoding</literal> (allow only if client encoding does not allow ASCII <literal>\</literal> within a multibyte character). <literal>safe_encoding</literal> is the default setting. 文字列リテラルの中で引用符が\'で表現されるかどうかを管理します。 引用符の表現としてSQL準拠の方式では二重化（''）ですが、PostgreSQLは歴史的に\'も受け付けます。 とは言っても、いくつかのクライアント文字集合符号化方式において、最終バイトが数値的にASCIIの\に等しいマルチバイト文字があり、\'を使用するとセキュリティ上問題を引き起こす可能性があります。 クライアント側のコードが事実上エスケープを正しく扱わない場合、SQLインジェクション攻撃が可能になります。この危険性の回避は、サーバが逆スラッシュでエスケープされた引用符を含む問い合わせを拒絶するようにします。 許可されるbackslash_quoteの値は、on （常に \' を許可）,off （常に拒否）、およびsafe_encoding （クライアント符号化方式がASCIIの\を許可しないときのみ、マルチバイト文字内で許可）。 safe_encoding がデフォルトの設定。

Note that in a standard-conforming string literal, <literal>\</literal> just means <literal>\</literal> anyway. This parameter only affects the handling of non-standard-conforming literals, including escape string syntax (<literal>E'...'</literal>). 標準に従った文字列リテラルでは、\は単に\を意味するものです。 このパラメータのみが、エスケープ文字列構文（E'...'）を含む標準に従わないリテラルの取り扱いに影響します。

When on, a warning is issued if a backslash (<literal>\</literal>) appears in an ordinary string literal (<literal>'...'</literal> syntax) and <varname>standard_conforming_strings</varname> is off. The default is <literal>on</literal>. 有効の場合、通常の文字列リテラル（'...'構文）にバックスラッシュ（\）があり、standard_conforming_stringsが無効な場合、警告が発せられます。 デフォルトはonです。

Applications that wish to use backslash as escape should be modified to use escape string syntax (<literal>E'...'</literal>), because the default behavior of ordinary strings is now to treat backslash as an ordinary character, per SQL standard. This variable can be enabled to help locate code that needs to be changed. 通常文字列のデフォルトの振る舞いは、SQL標準ではバックスラッシュを通常文字として取り扱うため、バックスラッシュをエスケープとして使用したいアプリケーションは、エスケープ文字列構文(E'...')を使用するように変更すべきです。 この変数は変更すべきコードを突き止めるのに役立つよう、有効にすることができます。

In <productname>PostgreSQL</productname> releases prior to 9.0, large objects did not have access privileges and were, therefore, always readable and writable by all users. Setting this variable to <literal>on</literal> disables the new privilege checks, for compatibility with prior releases. The default is <literal>off</literal>. Only superusers and users with the appropriate <literal>SET</literal> privilege can change this setting. 9.0以前のPostgreSQLリリースでは、ラージオブジェクトはアクセス権限が無く、従って全てのユーザが常に読み込み、書き込みが可能でした。 この変数をonにすると、以前のリリースとの互換性のため、新規の権限チェックが無効になります。 デフォルトはoffです。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。

Setting this variable does not disable all security checks related to large objects &mdash; only those for which the default behavior has changed in <productname>PostgreSQL</productname> 9.0. この変数を設定しても、ラージオブジェクトに関連した全ての安全性チェックを無効にする訳ではありません。 PostgreSQL 9.0で変更されたデフォルトの動きに対してのみです。

When the database generates SQL, force all identifiers to be quoted, even if they are not (currently) keywords. This will affect the output of <command>EXPLAIN</command> as well as the results of functions like <function>pg_get_viewdef</function>. See also the <option>&#45;-quote-all-identifiers</option> option of <xref linkend="app-pgdump"/> and <xref linkend="app-pg-dumpall"/>. データベースがSQLを生成する時、たとえ（現在）キーワードになっていなくても、全ての識別子を引用符で囲むことを強制します。 これは EXPLAINの出力に影響を与えるのみならず、pg_get_viewdefのような関数の結果にも影響します。 pg_dump および pg_dumpallの--quote-all-identifiersオプションも参照してください。

This controls whether ordinary string literals (<literal>'...'</literal>) treat backslashes literally, as specified in the SQL standard. Beginning in <productname>PostgreSQL</productname> 9.1, the default is <literal>on</literal> (prior releases defaulted to <literal>off</literal>). Applications can check this parameter to determine how string literals will be processed. The presence of this parameter can also be taken as an indication that the escape string syntax (<literal>E'...'</literal>) is supported. Escape string syntax (<xref linkend="sql-syntax-strings-escape"/>) should be used if an application desires backslashes to be treated as escape characters. 標準SQLで規定されたように、通常の文字列リテラル（'...'）がバックスラッシュをそのまま取り扱うか否かを制御します。 PostgreSQL 9.1からデフォルトはonになっています（それ以前のリリースではoffがデフォルトでした）。 どのように文字列リテラルが処理されるかを決めるこのパラメータを、アプリケーションで検査することができます。 このパラメータの存在は、エスケープ文字列構文（E'...'）がサポートされているかどうかを示すものとも考えられます。 エスケープ文字列構文 (4.1.2.2)は、アプリケーションでバックスラッシュをエスケープ文字として扱いたい場合に使用すべきです。

This allows sequential scans of large tables to synchronize with each other, so that concurrent scans read the same block at about the same time and hence share the I/O workload. When this is enabled, a scan might start in the middle of the table and then <quote>wrap around</quote> the end to cover all rows, so as to synchronize with the activity of scans already in progress. This can result in unpredictable changes in the row ordering returned by queries that have no <literal>ORDER BY</literal> clause. Setting this parameter to <literal>off</literal> ensures the pre-8.3 behavior in which a sequential scan always starts from the beginning of the table. The default is <literal>on</literal>. これにより、同時実行スキャンがほぼ同じ時間に同じブロックを読み取り、I/Oへの負荷を分散できるように、互いに同期して、大規模テーブルをシーケンシャルスキャンすることができます。 これが有効な場合、スキャンはテーブルの途中から始まり、進行中のスキャンの活動と同期するように、行全体を覆うように終端を「巻き上げる」可能性があります。 これにより、ORDER BY句を持たない問い合わせが返す行の順序は予想できない程変わってしまいます。 このパラメータをoffにすることで、シーケンシャルスキャンが常にテーブルの先頭から始まるという、8.3より前の動作を保証します。 デフォルトはonです。

When on, expressions of the form <literal><replaceable>expr</replaceable> = NULL</literal> (or <literal>NULL = <replaceable>expr</replaceable></literal>) are treated as <literal><replaceable>expr</replaceable> IS NULL</literal>, that is, they return true if <replaceable>expr</replaceable> evaluates to the null value, and false otherwise. The correct SQL-spec-compliant behavior of <literal><replaceable>expr</replaceable> = NULL</literal> is to always return null (unknown). Therefore this parameter defaults to <literal>off</literal>. 有効の場合、expr = NULL（もしくはNULL = expr）形式の式はexpr IS NULLとして取り扱われ、それは、もしexprがNULL値と評価すれば真を返し、そうでなければ偽を返します。 expr = NULLの正しいSQL仕様準拠の動作は常にNULL（判らない）を返すことです。 従って、このパラメータのデフォルトはoffになっています。

However, filtered forms in <productname>Microsoft Access</productname> generate queries that appear to use <literal><replaceable>expr</replaceable> = NULL</literal> to test for null values, so if you use that interface to access the database you might want to turn this option on. Since expressions of the form <literal><replaceable>expr</replaceable> = NULL</literal> always return the null value (using the SQL standard interpretation), they are not very useful and do not appear often in normal applications so this option does little harm in practice. But new users are frequently confused about the semantics of expressions involving null values, so this option is off by default. しかし、Microsoft Accessのフィルタ形式はNULL値を検査するためにexpr = NULLを使用する問い合わせを生成しますので、そのインタフェースを使用してデータベースにアクセスする場合は、このオプションを有効にする方が良いでしょう。 expr = NULLという形の式は（SQL標準解釈を使用した結果）常にNULL値を返しますので、通常のアプリケーションでは意味がほとんどなく、滅多に使用されません。 ですので、このオプションは実際は害はありません。 しかし、慣れていないユーザはしばしばNULL値に関する式の意味に戸惑いますので、デフォルトでこのオプションはoffです。

Note that this option only affects the exact form <literal>= NULL</literal>, not other comparison operators or other expressions that are computationally equivalent to some expression involving the equals operator (such as <literal>IN</literal>). Thus, this option is not a general fix for bad programming. このオプションは= NULLという形式にのみ影響することに注意してください。 他の比較演算子や等価演算子を呼び出す他の（INのような）式と計算する上で等価となる式には影響を与えません。 したがって、このオプションは間違ったプログラミングの汎用的な問題解決を行いません。

Refer to <xref linkend="functions-comparison"/> for related information. 関連する情報は9.2を参照してください。