@@ -1335,9 +1335,9 @@ SELECT b, char_length(b) FROM test2;
1335
1335
per byte, most significant nibble first. The entire string is
1336
1336
preceded by the sequence <literal>\x</literal> (to distinguish it
1337
1337
from the escape format). In some contexts, the initial backslash may
1338
- need to be escaped by doubling it, in the same cases in which backslashes
1339
- have to be doubled in escape format; details appear below .
1340
- The hexadecimal digits can
1338
+ need to be escaped by doubling it
1339
+ (see <xref linkend="sql-syntax-strings"/>) .
1340
+ For input, the hexadecimal digits can
1341
1341
be either upper or lower case, and whitespace is permitted between
1342
1342
digit pairs (but not within a digit pair nor in the starting
1343
1343
<literal>\x</literal> sequence).
@@ -1379,9 +1379,7 @@ SELECT '\xDEADBEEF';
1379
1379
values <emphasis>must</emphasis> be escaped, while all octet
1380
1380
values <emphasis>can</emphasis> be escaped. In
1381
1381
general, to escape an octet, convert it into its three-digit
1382
- octal value and precede it
1383
- by a backslash (or two backslashes, if writing the value as a
1384
- literal using escape string syntax).
1382
+ octal value and precede it by a backslash.
1385
1383
Backslash itself (octet decimal value 92) can alternatively be represented by
1386
1384
double backslashes.
1387
1385
<xref linkend="datatype-binary-sqlesc"/>
@@ -1398,7 +1396,7 @@ SELECT '\xDEADBEEF';
1398
1396
<entry>Description</entry>
1399
1397
<entry>Escaped Input Representation</entry>
1400
1398
<entry>Example</entry>
1401
- <entry>Output Representation</entry>
1399
+ <entry>Hex Representation</entry>
1402
1400
</row>
1403
1401
</thead>
1404
1402
@@ -1422,7 +1420,7 @@ SELECT '\xDEADBEEF';
1422
1420
<row>
1423
1421
<entry>92</entry>
1424
1422
<entry>backslash</entry>
1425
- <entry><literal>'\'</literal> or <literal>'\ \134'</literal></entry>
1423
+ <entry><literal>'\\ '</literal> or <literal>'\134'</literal></entry>
1426
1424
<entry><literal>SELECT '\\'::bytea;</literal></entry>
1427
1425
<entry><literal>\x5c</literal></entry>
1428
1426
</row>
@@ -1442,39 +1440,35 @@ SELECT '\xDEADBEEF';
1442
1440
<para>
1443
1441
The requirement to escape <emphasis>non-printable</emphasis> octets
1444
1442
varies depending on locale settings. In some instances you can get away
1445
- with leaving them unescaped. Note that the result in each of the examples
1446
- in <xref linkend="datatype-binary-sqlesc"/> was exactly one octet in
1447
- length, even though the output representation is sometimes
1448
- more than one character.
1443
+ with leaving them unescaped.
1449
1444
</para>
1450
1445
1451
1446
<para>
1452
- The reason multiple backslashes are required, as shown
1453
- in <xref linkend="datatype-binary-sqlesc"/>, is that an input
1454
- string written as a string literal must pass through two parse
1455
- phases in the <productname>PostgreSQL</productname> server.
1456
- The first backslash of each pair is interpreted as an escape
1457
- character by the string-literal parser (assuming escape string
1458
- syntax is used) and is therefore consumed, leaving the second backslash of the
1459
- pair. (Dollar-quoted strings can be used to avoid this level
1460
- of escaping.) The remaining backslash is then recognized by the
1461
- <type>bytea</type> input function as starting either a three
1462
- digit octal value or escaping another backslash. For example,
1463
- a string literal passed to the server as <literal>'\001'</literal>
1464
- becomes <literal>\001</literal> after passing through the
1465
- escape string parser. The <literal>\001</literal> is then sent
1466
- to the <type>bytea</type> input function, where it is converted
1467
- to a single octet with a decimal value of 1. Note that the
1468
- single-quote character is not treated specially by <type>bytea</type>,
1469
- so it follows the normal rules for string literals. (See also
1470
- <xref linkend="sql-syntax-strings"/>.)
1447
+ The reason that single quotes must be doubled, as shown
1448
+ in <xref linkend="datatype-binary-sqlesc"/>, is that this
1449
+ is true for any string literal in a SQL command. The generic
1450
+ string-literal parser consumes the outermost single quotes
1451
+ and reduces any pair of single quotes to one data character.
1452
+ What the <type>bytea</type> input function sees is just one
1453
+ single quote, which it treats as a plain data character.
1454
+ However, the <type>bytea</type> input function treats
1455
+ backslashes as special, and the other behaviors shown in
1456
+ <xref linkend="datatype-binary-sqlesc"/> are implemented by
1457
+ that function.
1458
+ </para>
1459
+
1460
+ <para>
1461
+ In some contexts, backslashes must be doubled compared to what is
1462
+ shown above, because the generic string-literal parser will also
1463
+ reduce pairs of backslashes to one data character;
1464
+ see <xref linkend="sql-syntax-strings"/>.
1471
1465
</para>
1472
1466
1473
1467
<para>
1474
1468
<type>Bytea</type> octets are output in <literal>hex</literal>
1475
1469
format by default. If you change <xref linkend="guc-bytea-output"/>
1476
1470
to <literal>escape</literal>,
1477
- <quote>non-printable</quote> octet are converted to
1471
+ <quote>non-printable</quote> octets are converted to their
1478
1472
equivalent three-digit octal value and preceded by one backslash.
1479
1473
Most <quote>printable</quote> octets are output by their standard
1480
1474
representation in the client character set, e.g.:
0 commit comments