From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Keary Suska <hierophant(at)pcisys(dot)net> |
Cc: | Postgres-Interfaces <pgsql-interfaces(at)postgresql(dot)org> |
Subject: | Re: Libpq and PGConn |
Date: | 2006-03-29 22:09:40 |
Message-ID: | 1330.1143670180@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Keary Suska <hierophant(at)pcisys(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Keary Suska | 2006-03-30 04:20:21 | PQexecPrepared Problem with paramValues |
Previous Message | Keary Suska | 2006-03-29 21:18:46 | Re: Libpq and PGConn |