
I'm beginning to think I created my own error!  After looking over the
sources I'm thinking I did the cut-n-paste from the same source but a
different function (if that makes sense).

I just sent patches for libpq++ to return an int (I'll also submit changes
to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
I just haven't been able to convince it to return a NULL.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================



Tue, 05 Oct 1999 22:47:42 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
libpq++ doc error?
Vince Vielhaber <vev@michvhf.com> writes:
> I just sent patches for libpq++ to return an int (I'll also submit changes
> to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
> I just haven't been able to convince it to return a NULL.

It won't.  If you look at the source, it's quite clear that it never
returns NULL.  It will return an empty string ("") if it notices a
problem.

Also, if you wanted to be really paranoid you'd check that what it
returns actually looks like it is a number, because PQcmdTuples doesn't
check that there is a number in the right spot in the command status
returned by the backend.

These two points together are why I suggested testing for an initial
digit...

			regards, tom lane

Wed, 06 Oct 1999 10:10:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] libpq++ doc error? 
On Wed, 6 Oct 1999, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > I just sent patches for libpq++ to return an int (I'll also submit changes
> > to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
> > I just haven't been able to convince it to return a NULL.
> 
> It won't.  If you look at the source, it's quite clear that it never
> returns NULL.  It will return an empty string ("") if it notices a
> problem.
> 
> Also, if you wanted to be really paranoid you'd check that what it
> returns actually looks like it is a number, because PQcmdTuples doesn't
> check that there is a number in the right spot in the command status
> returned by the backend.
> 
> These two points together are why I suggested testing for an initial
> digit...

Ok, I'm looking for an empty string now and that will return a -1.  The
other return possibilities *should* be handled correctly by atoi() since
it doesn't care if there's any leading blanks/spaces, as long as it's
not a non-numeric non-space character.  If it's going to get that crazy
with differing possibilities then we'd be further ahead to fix it in 
either the backend or in libpq (by adding a new function and letting
this one fade away).   Is there an atoi() out there that would not return
a 123 if passed the string "      123    " ??  It does the right thing in
hpux8 and in FreeBSD 3.2.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
  # include <std/disclaimers.h>       Have you seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Wed, 6 Oct 1999 10:52:34 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] libpq++ doc error? 