Re: [HACKERS] library policy question

> Hmm, we do have a bit of a problem here.  While PQconnectdb can be
> replaced by PQsetdb to avoid the concurrency issue, there is no
> thread-safe equivalent for the new routines
> PQconnectStart/PQconnectPoll.  That may not matter much, because
> probably you would only need those in a single-threaded environment,
> but it's still kinda ugly.  In any case it'd be a lot nicer to be
> able to say "libpq is thread safe" rather than "almost thread safe".
> 
> At one point we had discussed going ahead and breaking compatibility
> in order to get rid of the static PQconninfoOption array.  It wouldn't
> be a big change in the API: we'd only need to make PQconndefaults return
> a malloc'd array instead of a static.  That probably wouldn't really
> break any existing code, just create a small memory leak in applications
> that didn't know to free the result when they were done with it.  My bet
> is that very few apps use PQconndefaults anyway.
> 
> 7.0 would be a good time to do that if we were gonna do it.  Comments?
> 

Seems like a good time to do it.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026