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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026