Alternatively, UUID values can be generated
    outside of the database using any algorithm.  The data type <type>uuid</type> can be used
    to store any UUID, regardless of the origin and the UUID version.
   </para>

   <para>
    A UUID is written as a sequence of lower-case hexadecimal digits,
    in several groups separated by hyphens, specifically a group of 8
    digits followed by three groups of 4 digits followed by a group of
    12 digits, for a total of 32 digits representing the 128 bits.  An
    example of a UUID in this standard form is:
<programlisting>
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11
</programlisting>
    <productname>PostgreSQL</productname> also accepts the following
    alternative forms for input:
    use of upper-case digits, the standard format surrounded by
    braces, omitting some or all hyphens, adding a hyphen after any
    group of four digits.  Examples are:
<programlisting>
A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11
{a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11}
a0eebc999c0b4ef8bb6d6bb9bd380a11
a0ee-bc99-9c0b-4ef8-bb6d-6bb9-bd38-0a11
{a0eebc99-9c0b4ef8-bb6d6bb9-bd380a11}
</programlisting>
    Output is always in the standard form.
   </para>

   <para>
    See <xref linkend="functions-uuid"/> for how to generate a UUID in
    <productname>PostgreSQL</productname>.
   </para>
  </sect1>

  <sect1 id="datatype-xml">
   <title><acronym>XML</acronym> Type</title>

   <indexterm zone="datatype-xml">
    <primary>XML</primary>
   </indexterm>

   <para>
    The <type>xml</type> data type can be used to store XML data.  Its
    advantage over storing XML data in a <type>text</type> field is that it
    checks the input values for well-formedness, and there are support
    functions to perform type-safe operations on it; see <xref
    linkend="functions-xml"/>.  Use of this data type requires the
    installation to have been built with <command>configure
    --with-libxml</command>.
   </para>

   <para>
    The <type>xml</type> type can store well-formed
    <quote>documents</quote>, as defined by the XML standard, as well
    as <quote>content</quote> fragments, which are defined by reference
    to the more permissive
    <ulink url="https://www.w3.org/TR/2010/REC-xpath-datamodel-20101214/#DocumentNode"><quote>document node</quote></ulink>
    of the XQuery and XPath data model.
    Roughly, this means that content fragments can have
    more than one top-level element or character node.  The expression
    <literal><replaceable>xmlvalue</replaceable> IS DOCUMENT</literal>
    can be used to evaluate whether a particular <type>xml</type>
    value is a full document or only a content fragment.
   </para>

   <para>
    Limits and compatibility notes for the <type>xml</type> data type
    can be found in <xref linkend="xml-limits-conformance"/>.
   </para>

   <sect2 id="datatype-xml-creating">
    <title>Creating XML Values</title>
   <para>
    To produce a value of type <type>xml</type> from character data,
    use the function
    <function>xmlparse</function>:<indexterm><primary>xmlparse</primary></indexterm>
<synopsis>
XMLPARSE ( { DOCUMENT | CONTENT } <replaceable>value</replaceable>)
</synopsis>
    Examples:
<programlisting><![CDATA[
XMLPARSE (DOCUMENT '<?xml version="1.0"?><book><title>Manual</title><chapter>...</chapter></book>')
XMLPARSE (CONTENT 'abc<foo>bar</foo><bar>foo</bar>')
]]></programlisting>
    While this is the only way to convert character strings into XML
    values according to the SQL standard, the PostgreSQL-specific
    syntaxes:
<programlisting><![CDATA[
xml '<foo>bar</foo>'
'<foo>bar</foo>'::xml
]]></programlisting>
    can also be used.
   </para>

   <para>
    The <type>xml</type> type does not validate input values
    against a document type declaration
    (DTD),<indexterm><primary>DTD</primary></indexterm>
    even when the input value specifies a DTD.
    There is also currently no built-in support for validating against
    other XML schema languages such as XML Schema.