version 7.4.5

using postgresql-7.4.5/src/test/examples/testlibpq as follows

"testlibpq hostname=shouldHaveUsedHostNotHostname"

fails with coredump

SunOS pluto 5.9 Generic_117171-07 sun4u sparc SUNW,Ultra-5_10



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

On Wed, Sep 29, 2004 at 05:59:37PM +0100, Trevor Inns wrote:
Confirmed on Solaris 9 with PostgreSQL 8.0.0beta3 (CVS). Here's
a stack trace:

#0 0xff1344e4 in strlen () from /usr/lib/libc.so.1
#1 0xff186bec in _doprnt () from /usr/lib/libc.so.1
#2 0xff18861c in fprintf () from /usr/lib/libc.so.1
#3 0x00010a08 in main (argc=135304, argv=0x10cd8) at testlibpq.c:44

Here's line 44:

fprintf(stderr, "Connection to database '%s' failed.\n", PQdb(conn));

PQdb() is returning NULL, which causes fprintf() to dump core.
On FreeBSD 4.10-STABLE, fprintf() handles NULL:

Connection to database '(null)' failed.
invalid connection option "hostname"

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Michael Fuhr <mike (AT) fuhr (DOT) org> writes:
It is actually documented that a failed connection might return NULL for
this, so the example code is wrong. I've corrected the examples to not
assume PQdb can be used on a failed connection.

pg_dump was doing it wrong too :-(

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org