Обсуждение: Libpq and PGConn

What happens if a null pointer is sent to any libpq function for the PGConn
parameter?

Thanks,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

Keary Suska <hierophant@pcisys.net> writes:
> What happens if a null pointer is sent to any libpq function for the PGConn
> parameter?

AFAIR they all check for that and fail in a reasonably clean fashion.
Have you found one that doesn't?
        regards, tom lane

on 3/29/06 10:15 AM, tgl@sss.pgh.pa.us purportedly said:

> Keary Suska <hierophant@pcisys.net> writes:
>> What happens if a null pointer is sent to any libpq function for the PGConn
>> parameter?
> 
> AFAIR they all check for that and fail in a reasonably clean fashion.
> Have you found one that doesn't?

Not as of yet. I am building a custom wrapper to libpq and trying to account
for situations such as an attempt to call a libpq function on a PGconn
object that has not been initialized, such as returned from PQconnectdb and
the like. Same goes for PGresult objects.

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?

Thanks,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

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