visible in the current schema search path.
   Again, a dot within double quotes loses its special meaning and is matched
   literally.  A relation pattern that contains two dots (<literal>.</literal>)
   is interpreted as a database name followed by a schema name pattern followed
   by an object name pattern.  The database name portion will not be treated as
   a pattern and must match the name of the currently connected database, else
   an error will be raised.
  </para>

  <para>
   A schema pattern that contains a dot (<literal>.</literal>) is interpreted
   as a database name followed by a schema name pattern.  For example,
   <literal>\dn mydb.*foo*</literal> displays all schemas whose schema name
   includes <literal>foo</literal>.  The database name portion will not be
   treated as a pattern and must match the name of the currently connected
   database, else an error will be raised.
  </para>

  <para>
   Advanced users can use regular-expression notations such as character
   classes, for example <literal>[0-9]</literal> to match any digit.  All regular
   expression special characters work as specified in
   <xref linkend="functions-posix-regexp"/>, except for <literal>.</literal> which
   is taken as a separator as mentioned above, <literal>*</literal> which is
   translated to the regular-expression notation <literal>.*</literal>,
   <literal>?</literal> which is translated to <literal>.</literal>, and
   <literal>$</literal> which is matched literally.  You can emulate
   these pattern characters at need by writing
   <literal>?</literal> for <literal>.</literal>,
   <literal>(<replaceable class="parameter">R</replaceable>+|)</literal> for
   <literal><replaceable class="parameter">R</replaceable>*</literal>, or
   <literal>(<replaceable class="parameter">R</replaceable>|)</literal> for
   <literal><replaceable class="parameter">R</replaceable>?</literal>.
   <literal>$</literal> is not needed as a regular-expression character since
   the pattern must match the whole name, unlike the usual
   interpretation of regular expressions (in other words, <literal>$</literal>
   is automatically appended to your pattern).  Write <literal>*</literal> at the
   beginning and/or end if you don't wish the pattern to be anchored.
   Note that within double quotes, all regular expression special characters
   lose their special meanings and are matched literally.  Also, the regular
   expression special characters are matched literally in operator name
   patterns (i.e., the argument of <literal>\do</literal>).
  </para>
  </refsect3>
 </refsect2>

 <refsect2>
  <title>Advanced Features</title>

   <refsect3 id="app-psql-variables" xreflabel="Variables">
    <title>Variables</title>

    <para>
    <application>psql</application> provides variable substitution
    features similar to common Unix command shells.
    Variables are simply name/value pairs, where the value
    can be any string of any length.  The name must consist of letters
    (including non-Latin letters), digits, and underscores.
    </para>

    <para>
    To set a variable, use the <application>psql</application> meta-command
    <command>\set</command>.  For example,
<programlisting>
testdb=&gt; <userinput>\set foo bar</userinput>
</programlisting>
    sets the variable <literal>foo</literal> to the value
    <literal>bar</literal>. To retrieve the content of the variable, precede
    the name with a colon, for example:
<programlisting>
testdb=&gt; <userinput>\echo :foo</userinput>
bar
</programlisting>
    This works in both regular SQL commands and meta-commands; there is
    more detail in <xref linkend="app-psql-interpolation"/>, below.
    </para>

    <para>
    If you call <command>\set</command> without a second argument, the
    variable is set to an empty-string value. To unset (i.e., delete)
    a variable, use the command <command>\unset</command>.  To show the
    values of all variables, call <command>\set</command> without any argument.