<envar>PGDATABASE</envar>, <envar>PGHOST</envar>,
    <envar>PGPORT</envar> and/or <envar>PGUSER</envar> to appropriate
    values. (For additional environment variables, see <xref
    linkend="libpq-envars"/>.) It is also convenient to have a
    <filename>~/.pgpass</filename> file to avoid regularly having to type in
    passwords. See <xref linkend="libpq-pgpass"/> for more information.
    </para>

    <para>
     An alternative way to specify connection parameters is in a
     <parameter>conninfo</parameter> string or
     a <acronym>URI</acronym>, which is used instead of a database
     name. This mechanism give you very wide control over the
     connection. For example:
<programlisting>
$ <userinput>psql "service=myservice sslmode=require"</userinput>
$ <userinput>psql postgresql://dbmaster:5433/mydb?sslmode=require</userinput>
</programlisting>
     This way you can also use <acronym>LDAP</acronym> for connection
     parameter lookup as described in <xref linkend="libpq-ldap"/>.
     See <xref linkend="libpq-paramkeywords"/> for more information on all the
     available connection options.
    </para>

    <para>
    If the connection could not be made for any reason (e.g., insufficient
    privileges, server is not running on the targeted host, etc.),
    <application>psql</application> will return an error and terminate.
    </para>

    <para>
     If both standard input and standard output are a
     terminal, then <application>psql</application> sets the client
     encoding to <quote>auto</quote>, which will detect the
     appropriate client encoding from the locale settings
     (<envar>LC_CTYPE</envar> environment variable on Unix systems).
     If this doesn't work out as expected, the client encoding can be
     overridden using the environment
     variable <envar>PGCLIENTENCODING</envar>.
    </para>
  </refsect2>

  <refsect2 id="r2-app-psql-4">
    <title>Entering SQL Commands</title>

    <para>
    In normal operation, <application>psql</application> provides a
    prompt with the name of the database to which
    <application>psql</application> is currently connected, followed by
    the string <literal>=&gt;</literal>. For example:
<programlisting>
$ <userinput>psql testdb</userinput>
psql (&version;)
Type "help" for help.

testdb=&gt;
</programlisting>
    </para>

    <para>
    At the prompt, the user can type in <acronym>SQL</acronym> commands.
    Ordinarily, input lines are sent to the server when a
    command-terminating semicolon is reached. An end of line does not
    terminate a command.  Thus commands can be spread over several lines for
    clarity. If the command was sent and executed without error, the results
    of the command are displayed on the screen.
    </para>

    <para>
    If untrusted users have access to a database that has not adopted a
    <link linkend="ddl-schemas-patterns">secure schema usage pattern</link>,
    begin your session by removing publicly-writable schemas
    from <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>