<varname>search_path</varname>.  One can
    add <literal>options=-csearch_path=</literal> to the connection string or
    issue <literal>SELECT pg_catalog.set_config('search_path', '',
    false)</literal> before other SQL commands.  This consideration is not
    specific to <application>psql</application>; it applies to every interface
    for executing arbitrary SQL commands.
    </para>

    <para>
    Whenever a command is executed, <application>psql</application> also polls
    for asynchronous notification events generated by
    <link linkend="sql-listen"><command>LISTEN</command></link> and
    <link linkend="sql-notify"><command>NOTIFY</command></link>.
    </para>

    <para>
    While C-style block comments are passed to the server for
    processing and removal, SQL-standard comments are removed by
    <application>psql</application>.
    </para>
  </refsect2>

  <refsect2 id="app-psql-meta-commands">
    <title>Meta-Commands</title>

    <para>
    Anything you enter in <application>psql</application> that begins
    with an unquoted backslash is a <application>psql</application>
    meta-command that is processed by <application>psql</application>
    itself. These commands make
    <application>psql</application> more useful for administration or
    scripting. Meta-commands are often called slash or backslash commands.
    </para>

    <para>
    The format of a <application>psql</application> command is the backslash,
    followed immediately by a command verb, then any arguments. The arguments
    are separated from the command verb and each other by any number of
    whitespace characters.
    </para>

    <para>
    To include whitespace in an argument you can quote it with
    single quotes. To include a single quote in an argument,
    write two single quotes within single-quoted text.
    Anything contained in single quotes is
    furthermore subject to C-like substitutions for
    <literal>\n</literal> (new line), <literal>\t</literal> (tab),
    <literal>\b</literal> (backspace), <literal>\r</literal> (carriage return),
    <literal>\f</literal> (form feed),
    <literal>\</literal><replaceable>digits</replaceable> (octal), and
    <literal>\x</literal><replaceable>digits</replaceable> (hexadecimal).
    A backslash preceding any other character within single-quoted text
    quotes that single character, whatever it is.
    </para>

    <para>
    If an unquoted colon (<literal>:</literal>) followed by a
    <application>psql</application> variable name appears within an argument, it is
    replaced by the variable's value, as described in <xref
    linkend="app-psql-interpolation"/> below.
    The forms <literal>:'<replaceable>variable_name</replaceable>'</literal> and
    <literal>:"<replaceable>variable_name</replaceable>"</literal> described there
    work as well.
    The <literal>:{?<replaceable>variable_name</replaceable>}</literal> syntax allows
    testing whether a variable is defined. It is substituted by
    TRUE or FALSE.
    Escaping the colon with a backslash protects it from substitution.
    </para>

    <para>
    Within an argument, text that is enclosed in backquotes
    (<literal>`</literal>) is taken as a command line that is passed to the
    shell.  The output of the command (with any trailing newline removed)
    replaces the backquoted text.  Within the text enclosed in backquotes,
    no special quoting or other processing occurs, except that appearances
    of <literal>:<replaceable>variable_name</replaceable></literal> where
    <replaceable>variable_name</replaceable> is a <application>psql</application> variable name
    are replaced by the variable's value.  Also, appearances of
    <literal>:'<replaceable>variable_name</replaceable>'</literal> are replaced by the
    variable's value suitably quoted to become a single shell command
    argument.  (The latter form is almost always preferable, unless you are
    very sure of what is in the variable.)  Because carriage return