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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
