Re: [HACKERS] library policy question

Michael Meskes <meskes(at)postgreSQL(dot)org> writes:
> What exactly is our policy towards global variables in libraries?

Avoid them.

> But then libpq are is not suitable for multi threading, is it?

AFAIK, libpq's only use of non-constant globals is the ill-designed
PQconninfoOption array. I'd get rid of that if it didn't mean breaking
the library API. But as things stand, you can't safely use concurrent
calls to PQconnectdb or PQconndefaults. Everything else should be OK,
unless someone has broken it recently.

(idly examines code...)

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?

regards, tom lane