letters, which restricts them to match only
     <type>tsvector</type> lexemes with one of those weights:

<programlisting>
SELECT 'fat:ab &amp; cat'::tsquery;
    tsquery
------------------
 'fat':AB &amp; 'cat'
</programlisting>
    </para>

    <para>
     Also, lexemes in a <type>tsquery</type> can be labeled with <literal>*</literal>
     to specify prefix matching:
<programlisting>
SELECT 'super:*'::tsquery;
  tsquery
-----------
 'super':*
</programlisting>
     This query will match any word in a <type>tsvector</type> that begins
     with <quote>super</quote>.
    </para>

    <para>
     Quoting rules for lexemes are the same as described previously for
     lexemes in <type>tsvector</type>; and, as with <type>tsvector</type>,
     any required normalization of words must be done before converting
     to the <type>tsquery</type> type.  The <function>to_tsquery</function>
     function is convenient for performing such normalization:

<programlisting>
SELECT to_tsquery('Fat:ab &amp; Cats');
    to_tsquery
------------------
 'fat':AB &amp; 'cat'
</programlisting>

     Note that <function>to_tsquery</function> will process prefixes in the same way
     as other words, which means this comparison returns true:

<programlisting>
SELECT to_tsvector( 'postgraduate' ) @@ to_tsquery( 'postgres:*' );
 ?column?
----------
 t
</programlisting>
     because <literal>postgres</literal> gets stemmed to <literal>postgr</literal>:
<programlisting>
SELECT to_tsvector( 'postgraduate' ), to_tsquery( 'postgres:*' );
  to_tsvector  | to_tsquery
---------------+------------
 'postgradu':1 | 'postgr':*
</programlisting>
     which will match the stemmed form of <literal>postgraduate</literal>.
    </para>

   </sect2>

  </sect1>

  <sect1 id="datatype-uuid">
   <title><acronym>UUID</acronym> Type</title>

   <indexterm zone="datatype-uuid">
    <primary>UUID</primary>
   </indexterm>

   <para>
    The data type <type>uuid</type> stores Universally Unique Identifiers
    (UUID) as defined by <ulink url="https://datatracker.ietf.org/doc/html/rfc9562">RFC 9562</ulink>,
    ISO/IEC 9834-8:2005, and related standards.
    (Some systems refer to this data type as a globally unique identifier, or
    GUID,<indexterm><primary>GUID</primary></indexterm> instead.)  This
    identifier is a 128-bit quantity that is generated by an algorithm chosen
    to make it very unlikely that the same identifier will be generated by
    anyone else in the known universe using the same algorithm.  Therefore,
    for distributed systems, these identifiers provide a better uniqueness
    guarantee than sequence generators, which
    are only unique within a single database.
   </para>

   <para>
    RFC 9562 defines 8 different UUID versions.  Each version has specific requirements
    for generating new UUID values, and each version provides distinct benefits and drawbacks.
    <productname>PostgreSQL</productname> provides native support for generating UUIDs
    using the UUIDv4 and UUIDv7 algorithms.  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}