"madhtr" <madhtr@xxxxxxxxx> writes: > cleary I am going to have to study this documentation more carefully ... So > ... for simplicity's sake, If I just do the following, how do I get back > "database does not exist" ? [ shrug... ] Your program works perfectly for me: $ ./testit PQerrorMessage(lpcn) returns: FATAL: database "nonexistantdb" does not exist PQstatus(lpcn) returns 1 $ ... although it takes a good long while (several seconds) because of the "sleep(1)" in the interaction with the postmaster. Maybe your problem is not with the program, but with the postmaster you're trying to connect to? Does psql work? > source: http://www.postgresql.org/docs/7.3/static/libpq-connect.html Another line of thought, given the reading-between-the-lines conclusion that you are trying to use PG 7.3 libraries on Windows, is that there was something broken in the async-connect code back then on that platform. If you really are trying to do that, do yourself a favor and move to 8.0 or later. Nobody's going to be very interested in fixing 7.3. (I did try your program with 7.3 on Unix, though, and it seemed fine except the error message was spelled a bit differently.) > I was also under the assumption that I would not need to perform my own > selects on the underlying socket, and that whatever I got back would be > either a null pointer, a successful connection pointer, or a broken > connection pointer with an error indication. You don't *have* to perform selects on the underlying socket, but if you are not multiplexing this activity with some other I/O, I have to wonder why you are bothering with an asynchronous connect at all. What you've got at the moment is a poorly-implemented equivalent of PQconnectdb(). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
