index a066bb742ed7ebccd72e5c3a5beb2e8ab648630b..4bc950acf0bdf70ea2fb0ba0ebc7d3f6d18c4b2a 100644 (file)
-<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.180 2006年10月23日 18:10:30 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.181 2006年11月23日 04:27:33 momjian Exp $ -->
<chapter id="datatype">
<title id="datatype-title">Data Types</title>
</para>
<para>
- When entering <type>bytea</type> values, octets of certain values
- <emphasis>must</emphasis> be escaped (but all octet values
- <emphasis>can</emphasis> be escaped) when used as part of a string
- literal in an <acronym>SQL</acronym> statement. In general, to
- escape an octet, it is converted into the three-digit octal number
- equivalent of its decimal octet value, and preceded by two
- backslashes. <xref linkend="datatype-binary-sqlesc"> shows the
- characters that must be escaped, and gives the alternate escape
- sequences where applicable.
+ When entering <type>bytea</type> values, octets of certain
+ values <emphasis>must</emphasis> be escaped (but all octet
+ values <emphasis>can</emphasis> be escaped) when used as part
+ of a string literal in an <acronym>SQL</acronym> statement. In
+ general, to escape an octet, it is converted into the three-digit
+ octal number equivalent of its decimal octet value, and preceded
+ by two backslashes (or one backslash if
+ <varname>standard_conforming_strings</> is <literal>off</>).
+ <xref linkend="datatype-binary-sqlesc"> shows the characters
+ that must be escaped, and gives the alternate escape sequences
+ where applicable.
</para>
<table id="datatype-binary-sqlesc">
</para>
<para>
- The reason that you have to write so many backslashes, as shown in
- <xref linkend="datatype-binary-sqlesc">, is that an input string
- written as a string literal must pass through two parse phases in
- the <productname>PostgreSQL</productname> server. The first
- backslash of each pair is interpreted as an escape character by
- the string-literal parser and is therefore consumed, leaving the
- second backslash of the pair. The remaining backslash is then
- recognized by the <type>bytea</type> input function as starting
- either a three digit octal value or escaping another backslash.
- For example, a string literal passed to the server as
- <literal>'\001円'</literal> becomes <literal>001円</literal> after
- passing through the string-literal parser. The
- <literal>001円</literal> is then sent to the <type>bytea</type>
- input function, where it is converted to a single octet with a
- decimal value of 1. Note that the apostrophe character is not
- treated specially by <type>bytea</type>, so it follows the normal
- rules for string literals. (See also <xref
- linkend="sql-syntax-strings">.)
+ The reason that you have to write so many backslashes, as shown
+ in <xref linkend="datatype-binary-sqlesc">, is that an input
+ string written as a string literal must pass through two parse
+ phases in the <productname>PostgreSQL</productname> server.
+ The first backslash of each pair is interpreted as an escape
+ character by the string-literal parser (assuming
+ <varname>standard_conforming_strings</> is <literal>off</>)
+ and is therefore consumed, leaving the second backslash of the
+ pair. The remaining backslash is then recognized by the
+ <type>bytea</type> input function as starting either a three
+ digit octal value or escaping another backslash. For example,
+ a string literal passed to the server as <literal>'\001円'</literal>
+ becomes <literal>001円</literal> after passing through the
+ string-literal parser. The <literal>001円</literal> is then sent
+ to the <type>bytea</type> input function, where it is converted
+ to a single octet with a decimal value of 1. Note that the
+ apostrophe character is not treated specially by <type>bytea</type>,
+ so it follows the normal rules for string literals. (See also
+ <xref linkend="sql-syntax-strings">.)
</para>
<para>