id="libpq-connection-awaiting-response">
<term><symbol>CONNECTION_AWAITING_RESPONSE</symbol></term>
<listitem>
<para>
Waiting for a response from the server.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-connection-auth-ok">
<term><symbol>CONNECTION_AUTH_OK</symbol></term>
<listitem>
<para>
Received authentication; waiting for backend start-up to finish.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-connection-ssl-startup">
<term><symbol>CONNECTION_SSL_STARTUP</symbol></term>
<listitem>
<para>
Negotiating SSL encryption.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-connection-gss-startup">
<term><symbol>CONNECTION_GSS_STARTUP</symbol></term>
<listitem>
<para>
Negotiating GSS encryption.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-connection-check-writable">
<term><symbol>CONNECTION_CHECK_WRITABLE</symbol></term>
<listitem>
<para>
Checking if connection is able to handle write transactions.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-connection-check-standby">
<term><symbol>CONNECTION_CHECK_STANDBY</symbol></term>
<listitem>
<para>
Checking if connection is to a server in standby mode.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-connection-consume">
<term><symbol>CONNECTION_CONSUME</symbol></term>
<listitem>
<para>
Consuming any remaining response messages on connection.
</para>
</listitem>
</varlistentry>
</variablelist>
Note that, although these constants will remain (in order to maintain
compatibility), an application should never rely upon these occurring in a
particular order, or at all, or on the status always being one of these
documented values. An application might do something like this:
<programlisting>
switch(PQstatus(conn))
{
case CONNECTION_STARTED:
feedback = "Connecting...";
break;
case CONNECTION_MADE:
feedback = "Connected to server...";
break;
.
.
.
default:
feedback = "Connecting...";
}
</programlisting>
</para>
<para>
The <literal>connect_timeout</literal> connection parameter is ignored
when using <function>PQconnectPoll</function>; it is the application's
responsibility to decide whether an excessive amount of time has elapsed.
Otherwise, <function>PQconnectStart</function> followed by a
<function>PQconnectPoll</function> loop is equivalent to
<xref linkend="libpq-PQconnectdb"/>.
</para>
<para>
Note that when <function>PQconnectStart</function>
or <xref linkend="libpq-PQconnectStartParams"/> returns a non-null
pointer, you must call <xref linkend="libpq-PQfinish"/> when you are
finished with it, in order to dispose of the structure and any
associated memory blocks. This must be done even if the connection
attempt fails or is abandoned.
</para>
</listitem>
</varlistentry>
<varlistentry id="libpq-PQsocketPoll">
<term><function>PQsocketPoll</function><indexterm><primary>PQsocketPoll</primary></indexterm></term>
<listitem>
<para>
<indexterm><primary>nonblocking connection</primary></indexterm>
Poll a connection's underlying socket descriptor retrieved with
<xref linkend="libpq-PQsocket"/>.
The primary use of this function is iterating through the connection
sequence described in the documentation of
<xref linkend="libpq-PQconnectStartParams"/>.