reference), then the components of the target are
   passed through normal SQL parsing; this means that, for example,
   the <replaceable>hostname</replaceable> must look like one or more SQL
   identifiers separated by dots, and those identifiers will be
   case-folded unless double-quoted.  Values of
   any <replaceable>options</replaceable> must be SQL identifiers,
   integers, or variable references.  Of course, you can put nearly
   anything into an SQL identifier by double-quoting it.
   In practice, it is probably less error-prone to use a (single-quoted)
   string literal or a variable reference than to write the connection
   target directly.
  </para>

  <para>
   There are also different ways to specify the user name:

   <itemizedlist>
    <listitem>
     <simpara>
      <literal><replaceable>username</replaceable></literal>
     </simpara>
    </listitem>

    <listitem>
     <simpara>
      <literal><replaceable>username</replaceable>/<replaceable>password</replaceable></literal>
     </simpara>
    </listitem>

    <listitem>
     <simpara>
      <literal><replaceable>username</replaceable> IDENTIFIED BY <replaceable>password</replaceable></literal>
     </simpara>
    </listitem>

    <listitem>
     <simpara>
      <literal><replaceable>username</replaceable> USING <replaceable>password</replaceable></literal>
     </simpara>
    </listitem>
   </itemizedlist>

   As above, the parameters <replaceable>username</replaceable> and
   <replaceable>password</replaceable> can be an SQL identifier, an
   SQL string literal, or a reference to a character variable.
  </para>

  <para>
   If the connection target includes any <replaceable>options</replaceable>,
   those consist of
   <literal><replaceable>keyword</replaceable>=<replaceable>value</replaceable></literal>
   specifications separated by ampersands (<literal>&amp;</literal>).
   The allowed key words are the same ones recognized
   by <application>libpq</application> (see
   <xref linkend="libpq-paramkeywords"/>).  Spaces are ignored before
   any <replaceable>keyword</replaceable> or <replaceable>value</replaceable>,
   though not within or after one.  Note that there is no way to
   write <literal>&amp;</literal> within a <replaceable>value</replaceable>.
  </para>

  <para>
   Notice that when specifying a socket connection
   (with the <literal>unix:</literal> prefix), the host name must be
   exactly <literal>localhost</literal>.  To select a non-default
   socket directory, write the directory's pathname as the value of
   a <varname>host</varname> option in
   the <replaceable>options</replaceable> part of the target.
  </para>

  <para>
   The <replaceable>connection-name</replaceable> is used to handle
   multiple connections in one program.  It can be omitted if a
   program uses only one connection.  The most recently opened
   connection becomes the current connection, which is used by default
   when an SQL statement is to be executed (see later in this
   chapter).
  </para>

  <para>
   Here are some examples of <command>CONNECT</command> statements:
<programlisting>
EXEC SQL CONNECT TO mydb@sql.mydomain.com;

EXEC SQL CONNECT TO tcp:postgresql://sql.mydomain.com/mydb AS myconnection USER john;

EXEC SQL BEGIN DECLARE SECTION;
const char *target = "mydb@sql.mydomain.com";
const char *user = "john";
const char *passwd = "secret";
EXEC SQL END DECLARE SECTION;
 ...
EXEC SQL CONNECT TO :target USER :user USING :passwd;
/* or EXEC SQL CONNECT TO :target USER :user/:passwd; */
</programlisting>
   The last example makes use of the feature referred to above as
   character variable references.  You will see in later sections how C
   variables can be used in SQL statements when you prefix them with a
   colon.
  </para>

  <para>
   Be advised that the format of the connection target is not
   specified in the SQL standard.  So if you want to develop portable
   applications, you might want to use something based on the last
   example above to encapsulate