From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Alessandro Agosto" <the(dot)6one6(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Fwd: [LibPQ] Trying PQconnectStart: it doesn't seem to connect |
Date: | 2010-01-24 23:39:10 |
Message-ID: | 9fc66c8b-c8de-48da-9ef7-d9bc7b7d1da7@mm |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alessandro Agosto wrote:
> I'm not yet within select/poll cycle, this is the first call that should
> return CONNECTION_OK or CONNECTION_BAD (refering to docs).
That would be the behavior of PQconnectdb(), not PQconnectStart().
Have you read that part of the doc:
<quote>
Other states might also occur during (and only during) an asynchronous
connection procedure. These indicate the current stage of the connection
procedure and might be useful to provide feedback to the user for example.
These statuses are:
CONNECTION_STARTED
Waiting for connection to be made.
CONNECTION_MADE
Connection OK; waiting to send.
CONNECTION_AWAITING_RESPONSE
Waiting for a response from the server.
CONNECTION_AUTH_OK
Received authentication; waiting for backend start-up to finish.
CONNECTION_SSL_STARTUP
Negotiating SSL encryption.
CONNECTION_SETENV
Negotiating environment-driven parameter settings.
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:
switch(PQstatus(conn))
{
case CONNECTION_STARTED:
feedback = "Connecting...";
break;
case CONNECTION_MADE:
feedback = "Connected to server...";
break;
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-25 02:38:14 | Re: \dt+ sizes don't include TOAST data |
Previous Message | Alessandro Agosto | 2010-01-24 22:32:07 | Fwd: [LibPQ] Trying PQconnectStart: it doesn't seem to connect |