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 and line
    feed characters cannot be safely quoted on all platforms, the
    <literal>:'<replaceable>variable_name</replaceable>'</literal> form prints an
    error message and does not substitute the variable value when such
    characters appear in the value.
    </para>

    <para>
    Some commands take an <acronym>SQL</acronym> identifier (such as a
    table name) as argument. These arguments follow the syntax rules
    of <acronym>SQL</acronym>: Unquoted letters are forced to
    lowercase, while double quotes (<literal>"</literal>) protect letters
    from case conversion and allow incorporation of whitespace into
    the identifier.  Within double quotes, paired double quotes reduce
    to a single double quote in the resulting name.  For example,
    <literal>FOO"BAR"BAZ</literal> is interpreted as <literal>fooBARbaz</literal>,
    and <literal>"A weird"" name"</literal> becomes <literal>A weird"
    name</literal>.
    </para>

    <para>
    Parsing for arguments stops at the end of the line, or when another
    unquoted backslash is found.  An unquoted backslash
    is taken as the beginning of a new meta-command. The special
    sequence <literal>\\</literal> (two backslashes) marks the end of
    arguments and continues parsing <acronym>SQL</acronym> commands, if
    any. That way <acronym>SQL</acronym> and
    <application>psql</application> commands can be freely mixed on a
    line. But in any case, the arguments of a meta-command cannot
    continue beyond the end of the line.
    </para>

    <para>
    Many of the meta-commands act on the <firstterm>current query buffer</firstterm>.
    This is simply a buffer holding whatever SQL command text has been typed
    but not yet sent to the server for execution.  This will include previous
    input lines as well as any text appearing before the meta-command on the
    same line.
    </para>

    <para>
    Many of the meta-commands also allow <literal>x</literal> to be appended
    as an option. This will cause the results to be displayed in expanded
    mode, as if <command>\x</command> or <command>\pset expanded</command>
    had been used.
    </para>

    <para>
    The following meta-commands are defined:

    <variablelist>
      <varlistentry id="app-psql-meta-command-a">
        <term><literal>\a</literal></term>
        <listitem>
        <para>
        If the current table output format is unaligned, it is switched to aligned.
        If it is not unaligned, it is set to unaligned. This command is
        kept for backwards compatibility. See <command>\pset</command> for a
        more general solution.
        </para>
        </listitem>
      </varlistentry>

      <varlistentry id="app-psql-meta-command-bind">
       <term><literal>\bind</literal> [ <replaceable class="parameter">parameter</replaceable> ] ... </term>

       <listitem>
        <para>
         Sets query parameters for the next query execution, with the
         specified parameters passed for any parameter