1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>20.13. Version and Platform Compatibility</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="runtime-config-locks.html" title="20.12. Lock Management" /><link rel="next" href="runtime-config-error-handling.html" title="20.14. Error Handling" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">20.13. Version and Platform Compatibility</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-locks.html" title="20.12. Lock Management">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 20. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 20. Server Configuration</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 15.7 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="runtime-config-error-handling.html" title="20.14. Error Handling">Next</a></td></tr></table><hr /></div><div class="sect1" id="RUNTIME-CONFIG-COMPATIBLE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">20.13. Version and Platform Compatibility</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="runtime-config-compatible.html#RUNTIME-CONFIG-COMPATIBLE-VERSION">20.13.1. Previous PostgreSQL Versions</a></span></dt><dt><span class="sect2"><a href="runtime-config-compatible.html#RUNTIME-CONFIG-COMPATIBLE-CLIENTS">20.13.2. Platform and Client Compatibility</a></span></dt></dl></div><div class="sect2" id="RUNTIME-CONFIG-COMPATIBLE-VERSION"><div class="titlepage"><div><div><h3 class="title">20.13.1. Previous PostgreSQL Versions</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-ARRAY-NULLS"><span class="term"><code class="varname">array_nulls</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.2.2.1.1.3" class="indexterm"></a>
</span></dt><dd><p>
This controls whether the array input parser recognizes
unquoted <code class="literal">NULL</code> as specifying a null array element.
By default, this is <code class="literal">on</code>, allowing array values containing
null values to be entered. However, <span class="productname">PostgreSQL</span> versions
before 8.2 did not support null values in arrays, and therefore would
treat <code class="literal">NULL</code> as specifying a normal array element with
the string value <span class="quote">“<span class="quote">NULL</span>”</span>. For backward compatibility with
applications that require the old behavior, this variable can be
turned <code class="literal">off</code>.
</p><p>
Note that it is possible to create array values containing null values
even when this variable is <code class="literal">off</code>.
</p></dd><dt id="GUC-BACKSLASH-QUOTE"><span class="term"><code class="varname">backslash_quote</code> (<code class="type">enum</code>)
<a id="id-1.6.7.16.2.2.2.1.3" class="indexterm"></a>
<a id="id-1.6.7.16.2.2.2.1.4" class="indexterm"></a>
</span></dt><dd><p>
This controls whether a quote mark can be represented by
<code class="literal">\'</code> in a string literal. The preferred, SQL-standard way
to represent a quote mark is by doubling it (<code class="literal">''</code>) but
<span class="productname">PostgreSQL</span> has historically also accepted
<code class="literal">\'</code>. However, use of <code class="literal">\'</code> creates security risks
because in some client character set encodings, there are multibyte
characters in which the last byte is numerically equivalent to ASCII
<code class="literal">\</code>. 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 <code class="varname">backslash_quote</code> are
<code class="literal">on</code> (allow <code class="literal">\'</code> always),
<code class="literal">off</code> (reject always), and
<code class="literal">safe_encoding</code> (allow only if client encoding does not
allow ASCII <code class="literal">\</code> within a multibyte character).
<code class="literal">safe_encoding</code> is the default setting.
</p><p>
Note that in a standard-conforming string literal, <code class="literal">\</code> just
means <code class="literal">\</code> anyway. This parameter only affects the handling of
non-standard-conforming literals, including
escape string syntax (<code class="literal">E'...'</code>).
</p></dd><dt id="GUC-ESCAPE-STRING-WARNING"><span class="term"><code class="varname">escape_string_warning</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.2.2.3.1.3" class="indexterm"></a>
<a id="id-1.6.7.16.2.2.3.1.4" class="indexterm"></a>
</span></dt><dd><p>
When on, a warning is issued if a backslash (<code class="literal">\</code>)
appears in an ordinary string literal (<code class="literal">'...'</code>
syntax) and <code class="varname">standard_conforming_strings</code> is off.
The default is <code class="literal">on</code>.
</p><p>
Applications that wish to use backslash as escape should be
modified to use escape string syntax (<code class="literal">E'...'</code>),
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.
</p></dd><dt id="GUC-LO-COMPAT-PRIVILEGES"><span class="term"><code class="varname">lo_compat_privileges</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.2.2.4.1.3" class="indexterm"></a>
</span></dt><dd><p>
In <span class="productname">PostgreSQL</span> 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 <code class="literal">on</code>
disables the new privilege checks, for compatibility with prior
releases. The default is <code class="literal">off</code>.
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p><p>
Setting this variable does not disable all security checks related to
large objects — only those for which the default behavior has
changed in <span class="productname">PostgreSQL</span> 9.0.
</p></dd><dt id="GUC-QUOTE-ALL-IDENTIFIERS"><span class="term"><code class="varname">quote_all_identifiers</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.2.2.5.1.3" class="indexterm"></a>
</span></dt><dd><p>
When the database generates SQL, force all identifiers to be quoted,
even if they are not (currently) keywords. This will affect the
output of <code class="command">EXPLAIN</code> as well as the results of functions
like <code class="function">pg_get_viewdef</code>. See also the
<code class="option">--quote-all-identifiers</code> option of
<a class="xref" href="app-pgdump.html" title="pg_dump"><span class="refentrytitle"><span class="application">pg_dump</span></span></a> and <a class="xref" href="app-pg-dumpall.html" title="pg_dumpall"><span class="refentrytitle"><span class="application">pg_dumpall</span></span></a>.
</p></dd><dt id="GUC-STANDARD-CONFORMING-STRINGS"><span class="term"><code class="varname">standard_conforming_strings</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.2.2.6.1.3" class="indexterm"></a>
<a id="id-1.6.7.16.2.2.6.1.4" class="indexterm"></a>
</span></dt><dd><p>
This controls whether ordinary string literals
(<code class="literal">'...'</code>) treat backslashes literally, as specified in
the SQL standard.
Beginning in <span class="productname">PostgreSQL</span> 9.1, the default is
<code class="literal">on</code> (prior releases defaulted to <code class="literal">off</code>).
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 (<code class="literal">E'...'</code>) is supported.
Escape string syntax (<a class="xref" href="sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-ESCAPE" title="4.1.2.2. String Constants with C-Style Escapes">Section 4.1.2.2</a>)
should be used if an application desires
backslashes to be treated as escape characters.
</p></dd><dt id="GUC-SYNCHRONIZE-SEQSCANS"><span class="term"><code class="varname">synchronize_seqscans</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.2.2.7.1.3" class="indexterm"></a>
</span></dt><dd><p>
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 <span class="quote">“<span class="quote">wrap
around</span>”</span> 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 <code class="literal">ORDER BY</code> clause. Setting this parameter to
<code class="literal">off</code> ensures the pre-8.3 behavior in which a sequential
scan always starts from the beginning of the table. The default
is <code class="literal">on</code>.
</p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-COMPATIBLE-CLIENTS"><div class="titlepage"><div><div><h3 class="title">20.13.2. Platform and Client Compatibility</h3></div></div></div><div class="variablelist"><dl class="variablelist"><dt id="GUC-TRANSFORM-NULL-EQUALS"><span class="term"><code class="varname">transform_null_equals</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.16.3.2.1.1.3" class="indexterm"></a>
<a id="id-1.6.7.16.3.2.1.1.4" class="indexterm"></a>
</span></dt><dd><p>
When on, expressions of the form <code class="literal"><em class="replaceable"><code>expr</code></em> =
NULL</code> (or <code class="literal">NULL =
<em class="replaceable"><code>expr</code></em></code>) are treated as
<code class="literal"><em class="replaceable"><code>expr</code></em> IS NULL</code>, that is, they
return true if <em class="replaceable"><code>expr</code></em> evaluates to the null value,
and false otherwise. The correct SQL-spec-compliant behavior of
<code class="literal"><em class="replaceable"><code>expr</code></em> = NULL</code> is to always
return null (unknown). Therefore this parameter defaults to
<code class="literal">off</code>.
</p><p>
However, filtered forms in <span class="productname">Microsoft
Access</span> generate queries that appear to use
<code class="literal"><em class="replaceable"><code>expr</code></em> = NULL</code> 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 <code class="literal"><em class="replaceable"><code>expr</code></em> = NULL</code> 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.
</p><p>
Note that this option only affects the exact form <code class="literal">= NULL</code>,
not other comparison operators or other expressions
that are computationally equivalent to some expression
involving the equals operator (such as <code class="literal">IN</code>).
Thus, this option is not a general fix for bad programming.
</p><p>
Refer to <a class="xref" href="functions-comparison.html" title="9.2. Comparison Functions and Operators">Section 9.2</a> for related information.
</p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="runtime-config-locks.html" title="20.12. Lock Management">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html" title="Chapter 20. Server Configuration">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-error-handling.html" title="20.14. Error Handling">Next</a></td></tr><tr><td width="40%" align="left" valign="top">20.12. Lock Management </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 15.7 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 20.14. Error Handling</td></tr></table></div></body></html>
|
