<entry><literal>'\<replaceable>xxx'</replaceable></literal> (octal value)</entry>
       <entry><literal>'\001'::bytea</literal></entry>
       <entry><literal>\x01</literal></entry>
      </row>

     </tbody>
    </tgroup>
   </table>

   <para>
    The requirement to escape <emphasis>non-printable</emphasis> octets
    varies depending on locale settings. In some instances you can get away
    with leaving them unescaped.
   </para>

   <para>
    The reason that single quotes must be doubled, as shown
    in <xref linkend="datatype-binary-sqlesc"/>, is that this
    is true for any string literal in an SQL command.  The generic
    string-literal parser consumes the outermost single quotes
    and reduces any pair of single quotes to one data character.
    What the <type>bytea</type> input function sees is just one
    single quote, which it treats as a plain data character.
    However, the <type>bytea</type> input function treats
    backslashes as special, and the other behaviors shown in
    <xref linkend="datatype-binary-sqlesc"/> are implemented by
    that function.
   </para>

   <para>
    In some contexts, backslashes must be doubled compared to what is
    shown above, because the generic string-literal parser will also
    reduce pairs of backslashes to one data character;
    see <xref linkend="sql-syntax-strings"/>.
   </para>

   <para>
    <type>Bytea</type> octets are output in <literal>hex</literal>
    format by default.  If you change <xref linkend="guc-bytea-output"/>
    to <literal>escape</literal>,
    <quote>non-printable</quote> octets are converted to their
    equivalent three-digit octal value and preceded by one backslash.
    Most <quote>printable</quote> octets are output by their standard
    representation in the client character set, e.g.:

<programlisting>
SET bytea_output = 'escape';

SELECT 'abc \153\154\155 \052\251\124'::bytea;
     bytea
----------------
 abc klm *\251T
</programlisting>

    The octet with decimal value 92 (backslash) is doubled in the output.
    Details are in <xref linkend="datatype-binary-resesc"/>.
   </para>

   <table id="datatype-binary-resesc">
    <title><type>bytea</type> Output Escaped Octets</title>
    <tgroup cols="5">
     <colspec colname="col1" colwidth="1*"/>
     <colspec colname="col2" colwidth="1*"/>
     <colspec colname="col3" colwidth="1*"/>
     <colspec colname="col4" colwidth="1.25*"/>
     <colspec colname="col5" colwidth="1*"/>
     <thead>
      <row>
       <entry>Decimal Octet Value</entry>
       <entry>Description</entry>
       <entry>Escaped Output Representation</entry>
       <entry>Example</entry>
       <entry>Output Result</entry>
      </row>
     </thead>

     <tbody>

      <row>
       <entry>92</entry>
       <entry>backslash</entry>
       <entry><literal>\\</literal></entry>
       <entry><literal>'\134'::bytea</literal></entry>
       <entry><literal>\\</literal></entry>
      </row>

      <row>
       <entry>0 to 31 and 127 to 255</entry>
       <entry><quote>non-printable</quote> octets</entry>
       <entry><literal>\<replaceable>xxx</replaceable></literal> (octal value)</entry>
       <entry><literal>'\001'::bytea</literal></entry>
       <entry><literal>\001</literal></entry>
      </row>

      <row>
       <entry>32 to 126</entry>
       <entry><quote>printable</quote> octets</entry>
       <entry>client character set representation</entry>
       <entry><literal>'\176'::bytea</literal></entry>
       <entry><literal>~</literal></entry>
      </row>

     </tbody>
    </tgroup>
   </table>

   <para>
    Depending on the front end to <productname>PostgreSQL</productname> you use,
    you might have additional work to do in terms of escaping and
    unescaping <type>bytea</type> strings. For example, you might also
    have to escape line feeds and carriage returns if your interface
    automatically translates these.
   </para>
  </sect2>
 </sect1>


  <sect1 id="datatype-datetime">
   <title>Date/Time Types</title>