Re: Libpq and PGConn - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: Libpq and PGConn
Date
Msg-id 1330.1143670180@sss.pgh.pa.us
Whole thread Raw
In response to Re: Libpq and PGConn  (Keary Suska <hierophant@pcisys.net>)
List pgsql-interfaces
Keary Suska <hierophant@pcisys.net> writes:
> Is it safe to assume that in these cases--where a PGconn or Pgresult has not
> been initialized, but has not been finished() either--that all functions
> won't (or shouldn't) choke, will set an error message, and return a defined
> value?

Well, there isn't any place to "set an error message" if you don't have
a PGconn.  I think it's reasonable to expect libpq functions not to
crash on NULL pointer inputs, but there's a limit to what we can do
beyond not crashing.  Also, if you pass pointers to garbage memory
(rather than NULL pointers) all bets are off; which limits the value of
worrying about the NULL case anyway.  Ultimately, if the calling app is
broken enough to pass bad pointers there isn't a lot that a library can
do to defend itself.
        regards, tom lane


pgsql-interfaces by date:

Previous
From: Keary Suska
Date:
Subject: Re: Libpq and PGConn
Next
From: Keary Suska
Date:
Subject: PQexecPrepared Problem with paramValues