linkend="ddl-schemas-patterns">secure schema usage pattern</link>,
     begin each session by removing publicly-writable schemas from
     <varname>search_path</varname>.  One can set parameter key
     word <literal>options</literal> to
     value <literal>-csearch_path=</literal>.  Alternately, one can
     issue <literal>PQexec(<replaceable>conn</replaceable>, "SELECT
     pg_catalog.set_config('search_path', '', false)")</literal> after
     connecting.  This consideration is not specific
     to <application>libpq</application>; it applies to every interface for
     executing arbitrary SQL commands.
    </para>
   </warning>

   <warning>
    <para>
     On Unix, forking a process with open libpq connections can lead to
     unpredictable results because the parent and child processes share
     the same sockets and operating system resources.  For this reason,
     such usage is not recommended, though doing an <function>exec</function> from
     the child process to load a new executable is safe.
    </para>
   </warning>

   <variablelist>
    <varlistentry id="libpq-PQconnectdbParams">
     <term><function>PQconnectdbParams</function><indexterm><primary>PQconnectdbParams</primary></indexterm></term>
     <listitem>
      <para>
       Makes a new connection to the database server.

<synopsis>
PGconn *PQconnectdbParams(const char * const *keywords,
                          const char * const *values,
                          int expand_dbname);
</synopsis>
      </para>

      <para>
       This function opens a new database connection using the parameters taken
       from two <symbol>NULL</symbol>-terminated arrays. The first,
       <literal>keywords</literal>, is defined as an array of strings, each one
       being a key word. The second, <literal>values</literal>, gives the value
       for each key word. Unlike <xref linkend="libpq-PQsetdbLogin"/> below, the parameter
       set can be extended without changing the function signature, so use of
       this function (or its nonblocking analogs <xref linkend="libpq-PQconnectStartParams"/>
       and <function>PQconnectPoll</function>) is preferred for new application
       programming.
      </para>

      <para>
       The currently recognized parameter key words are listed in
       <xref linkend="libpq-paramkeywords"/>.
      </para>

      <para>
       The passed arrays can be empty to use all default parameters, or can
       contain one or more parameter settings. They must be matched in length.
       Processing will stop at the first <symbol>NULL</symbol> entry
       in the <literal>keywords</literal> array.
       Also, if the <literal>values</literal> entry associated with a
       non-<symbol>NULL</symbol> <literal>keywords</literal> entry is
       <symbol>NULL</symbol> or an empty string, that entry is ignored and
       processing continues with the next pair of array entries.
      </para>

      <para>
       When <literal>expand_dbname</literal> is non-zero, the value for
       the first <parameter>dbname</parameter> key word is checked to see
       if it is a <firstterm>connection string</firstterm>.  If so, it
       is <quote>expanded</quote> into the individual connection
       parameters extracted from the string.  The value is considered to
       be a connection string, rather than just a database name, if it
       contains an equal sign (<literal>=</literal>) or it begins with a
       URI scheme designator.  (More details on connection string formats
       appear in <xref linkend="libpq-connstring"/>.)  Only the first
       occurrence of <parameter>dbname</parameter> is treated in this way;
       any subsequent <parameter>dbname</parameter> parameter is processed
       as a plain database name.
      </para>

      <para>
       In general the parameter arrays are processed from start to end.
       If any key word is repeated, the last value (that is
       not <symbol>NULL</symbol> or empty) is used.  This rule applies in