pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: [INTERFACES] libpq problem (really libpq feature request)
4+ messages / 3 participants
[nested] [flat]
* Re: [INTERFACES] libpq problem (really libpq feature request)
@ 1999-07-28 04:25 Tim Allen <tim@proximity.com.au>
1999-07-28 14:04 ` Re: [INTERFACES] libpq problem (really libpq feature request) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Tim Allen @ 1999-07-28 04:25 UTC (permalink / raw)
To: pgsql-interfaces@hub.org
> Date: Tue, 27 Jul 1999 17:46:28 +0200
> From: "Jonathan davis" <haj@idianet.net>
>
> >"Jonathan davis" <haj@idianet.net> writes:
> >> with libpq, i can't difference between bad password and server down !!
> >
> >Are you paying attention to PQerrorMessage?
> >
> > regards, tom lane
> >
> I means errors with code (int)
I think Jonathan is alluding (in a rather obtuse manner :-)) to an issue
that is on my wishlist also, namely a more systematic way of identifying
errors. Currently, libpq gives you an error state (no error, nonfatal
error, or fatal error) and an error message. What would be nice is if
there was also some sort of error code (eg an integer) that identified the
exact nature of the problem. And, of course, a published spec of what the
error codes mean. Then it would be much easier for one's program to know
what the error was, and, if possible, do something about it. From my point
of view, there are basically two classes of error - programmer error, and
resource limitation error (eg network problems, disk space problems). The
fundamental difference is that for the latter, the user might be able to
do something about it, whereas for the former, you need to modify the
code. It would be good if a program could deduce which it was without
having to do anything silly and dangerous like trying to parse the error
message.
Tim
-----------------------------------------------
Tim Allen
Proximity Pty Ltd http://www.proximity.com.au
-----------------------------------------------
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] libpq problem (really libpq feature request)
1999-07-28 04:25 Re: [INTERFACES] libpq problem (really libpq feature request) Tim Allen <tim@proximity.com.au>
@ 1999-07-28 14:04 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 1999-07-28 14:04 UTC (permalink / raw)
To: Tim Allen <tim@proximity.com.au>; +Cc: pgsql-interfaces@hub.org
Tim Allen <tim@proximity.com.au> writes:
> I think Jonathan is alluding (in a rather obtuse manner :-)) to an issue
> that is on my wishlist also, namely a more systematic way of identifying
> errors. Currently, libpq gives you an error state (no error, nonfatal
> error, or fatal error) and an error message. What would be nice is if
> there was also some sort of error code (eg an integer) that identified the
> exact nature of the problem.
Yes, that is an item on the TODO list, I believe. The text error
messages are fine for human consumption, but not so great for programs
that want to try to cope with an error.
Aside from the cases you mention, there are "expected errors" that a
program might know about and want to recover from --- for example,
INSERT new_record INTO table_with_unique_index;
if (got error "Cannot insert duplicate key")
UPDATE table_with_unique_index SET data = new_record.data
WHERE key = new_record.key;
which works until someone decides to spell the error message a little
differently...
However, creating and maintaining the list of message codes is a lot
of very tedious, uninteresting work, and no one so far has had the
fortitude to actually do it. (One of the deficiencies of the open-
source model is that you can't assign some junior programmer to go do
the tasks no one else wants to do :-(.) Any volunteers out there?
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] libpq problem (really libpq feature request)
@ 1999-07-28 10:06 Jonathan davis <haj@idianet.net>
1999-07-28 14:14 ` Re: [INTERFACES] libpq problem (really libpq feature request) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Jonathan davis @ 1999-07-28 10:06 UTC (permalink / raw)
To: Tim Allen <tim@proximity.com.au>; pgsql-interfaces@hub.org
>I think Jonathan is alluding (in a rather obtuse manner :-)) to an issue
>that is on my wishlist also, namely a more systematic way of identifying
>errors. Currently, libpq gives you an error state (no error, nonfatal
>error, or fatal error) and an error message. What would be nice is if
>there was also some sort of error code (eg an integer) that identified the
>exact nature of the problem. And, of course, a published spec of what the
>error codes mean. Then it would be much easier for one's program to know
>what the error was, and, if possible, do something about it. From my point
>of view, there are basically two classes of error - programmer error, and
>resource limitation error (eg network problems, disk space problems). The
>fundamental difference is that for the latter, the user might be able to
>do something about it, whereas for the former, you need to modify the
>code. It would be good if a program could deduce which it was without
>having to do anything silly and dangerous like trying to parse the error
>message.
>
>Tim
>
the postgresql client is running under win98 and the server under FreeBSD3.1
when I'm trying to connect to the server and the server is not running, the
error message is:
connectDB() -- socket() failed:
errno=0
No error
and when the password is incorrect, i have the same error
it is no way to difference the errors !!!
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] libpq problem (really libpq feature request)
1999-07-28 10:06 Re: [INTERFACES] libpq problem (really libpq feature request) Jonathan davis <haj@idianet.net>
@ 1999-07-28 14:14 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Tom Lane @ 1999-07-28 14:14 UTC (permalink / raw)
To: Jonathan davis <haj@idianet.net>; +Cc: Tim Allen <tim@proximity.com.au>; pgsql-interfaces@hub.org
"Jonathan davis" <haj@idianet.net> writes:
> the postgresql client is running under win98 and the server under FreeBSD3.1
> when I'm trying to connect to the server and the server is not running, the
> error message is:
> connectDB() -- socket() failed:
> errno=0
> No error
> and when the password is incorrect, i have the same error
> it is no way to difference the errors !!!
That's because they are the same error --- if the socket() call is
failing then the client is not getting as far as attempting to contact
the server, let alone checking the password. I do not know why you
are not getting a useful errno value; probably another deficiency of
the Windoze socket code :-(. But I'd suggest looking at whether
TCP support is turned on, whether there is a problem linking the socket
support library into the application, etc. Any Win experts here with
an idea what could make socket() fail?
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~1999-07-28 14:14 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-07-28 04:25 Re: [INTERFACES] libpq problem (really libpq feature request) Tim Allen <tim@proximity.com.au>
1999-07-28 14:04 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-07-28 10:06 Re: [INTERFACES] libpq problem (really libpq feature request) Jonathan davis <haj@idianet.net>
1999-07-28 14:14 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox