output
      columns of <function>xmltable</function>), except for a few cases
      treated specially, <productname>PostgreSQL</productname> simply assumes
      that the XML data type's XPath 1.0 string form will be valid as the
      text-input form of the SQL datatype, and conversely. This rule has the
      virtue of simplicity while producing, for many data types, results similar
      to the mappings specified in the standard.
     </para>

     <para>
      Where interoperability with other systems is a concern, for some data
      types, it may be necessary to use data type formatting functions (such
      as those in <xref linkend="functions-formatting"/>) explicitly to
      produce the standard mappings.
     </para>
    </sect3>
   </sect2>

   <sect2 id="functions-xml-limits-postgresql">
    <title>Incidental Limits of the Implementation</title>

    <para>
     This section concerns limits that are not inherent in the
     <application>libxml2</application> library, but apply to the current
     implementation in <productname>PostgreSQL</productname>.
    </para>

    <sect3 id="functions-xml-limits-postgresql-by-value-only">
     <title>Only <literal>BY VALUE</literal> Passing Mechanism Is Supported</title>

     <para>
      The SQL standard defines two <firstterm>passing mechanisms</firstterm>
      that apply when passing an XML argument from SQL to an XML function or
      receiving a result: <literal>BY REF</literal>, in which a particular XML
      value retains its node identity, and <literal>BY VALUE</literal>, in which
      the content of the XML is passed but node identity is not preserved. A
      mechanism can be specified before a list of parameters, as the default
      mechanism for all of them, or after any parameter, to override the
      default.
     </para>

     <para>
      To illustrate the difference, if
      <replaceable>x</replaceable> is an XML value, these two queries in
      an SQL:2006 environment would produce true and false, respectively:

<programlisting>
SELECT XMLQUERY('$a is $b' PASSING BY REF <replaceable>x</replaceable> AS a, <replaceable>x</replaceable> AS b NULL ON EMPTY);
SELECT XMLQUERY('$a is $b' PASSING BY VALUE <replaceable>x</replaceable> AS a, <replaceable>x</replaceable> AS b NULL ON EMPTY);
</programlisting>
     </para>

     <para>
      <productname>PostgreSQL</productname> will accept
      <literal>BY VALUE</literal> or <literal>BY REF</literal> in an
      <function>XMLEXISTS</function> or <function>XMLTABLE</function>
      construct, but it ignores them.  The <type>xml</type> data type holds
      a character-string serialized representation, so there is no node
      identity to preserve, and passing is always effectively <literal>BY
      VALUE</literal>.
     </para>
    </sect3>

    <sect3 id="functions-xml-limits-postgresql-named-parameters">
     <title>Cannot Pass Named Parameters to Queries</title>

     <para>
      The XPath-based functions support passing one parameter to serve as the
      XPath expression's context item, but do not support passing additional
      values to be available to the expression as named parameters.
     </para>
    </sect3>

    <sect3 id="functions-xml-limits-postgresql-no-xml-sequence">
     <title>No <type>XML(SEQUENCE)</type> Type</title>

     <para>
      The <productname>PostgreSQL</productname> <type>xml</type> data type
      can only hold a value in <literal>DOCUMENT</literal>
      or <literal>CONTENT</literal> form.  An XQuery/XPath expression
      context item must be a single XML node or atomic value, but XPath 1.0
      further restricts it to be only an XML node, and has no node type
      allowing <literal>CONTENT</literal>.  The upshot is that a
      well-formed <literal>DOCUMENT</literal> is the only form of XML value
      that <productname>PostgreSQL</productname> can supply as an XPath
      context item.
     </para>
    </sect3>
   </sect2>
  </sect1>

 </appendix>