...

I've been thinking some about how exactly to provide the new option of
thread-safe clients (libpq, ecpg).  Let me state the following goals:

a. Thread-safeness, where it makes a difference, is generally thought to
be a performance hit, so the user needs to have a choice to use
thread-safe libraries or not.

b. The user needs to be able to make the choice at the time he builds his
application, *not* at the time the PostgreSQL distribution is built or
installed.

Clearly, a thread-safe ecpg library is always going to be significantly
different from the "normal" one, with all the mutex things that get pulled
in, so it seems reasonable to always offer a libecpg_r alongside the
libecpg.

The question is whether a libpq_r should be provided if libpq is
thread-safe by default (no *_r functions, libc_r, or special flags).  I
think yes.  It could be a symlink, so it doesn't really waste space. But
it would convenience users: Those who want to be sure to always link
against a thread-safe version can point to libpq_r and don't have to
create complicated detection mechanisms. Those who know that their system
is thread-safe by default can simply use libpq to follow that convention.
And of course it creates consistency with libecpg_r and does not bother
the user with complicated internal artifacts.

A final note on the name of the configure option, --with-threads. First,
it does not control an external package but an internal feature, so it
should be --enable-.  Secondly, it does not use threads, only enable
thread-safeness.  So --enable-thread-safe might be a better name.  Or if
you want to be more precise, --enable-thread-safe-client.  The latter is
what MySQL uses, in case anyone cares about that.

-- 
Peter Eisentraut   peter_e@gmx.net