On Wed, 10 Sep 2003 02:39 pm, Tom Lane wrote: > A thread-safe implementation of > libpq is of zero value to an application unless it also has thread-safe > implementations of the other libraries it depends on.
Not necessarily so - we've managed okay so far (several years) working on platforms that don't fall into that short list. It can be done. Thus far we have had to use Sybase or Informix because they do support thread-safe C interfaces. > Any app that might want to > use libpq is going to hit those same bugs, and so in the long run the > only useful answer is for the platform to fix its libc. The useful answer (so far) is to not use PostgreSQL for these applications, but to stick with a database that does support a threadsafe C interface. I think that's a pity. I agree, it would make life easier if vendors supported threadsafe libc functions. > The real bottom line here is: who is going to try to build threaded > apps on platforms with un-thread-safe libc? The company I work for. I got involved in this issue so we could port from Sybase and Informix to PostgreSQL. I assume there are other people out there who'd be interested as well. > And why should we be the > ones to try to save them from suffering the pain they deserve? 1) Leave users to cope with their own code issues, but make sure the database's C interface isn't one of them. 2) Because it's good enough for (Oracle|Informix|Sybase) So moving forward: do we try Bruce's idea of libpq_r and ecpg_r? If people want to risk the overhead of wrapped libc calls, they can build the threaded lib versions and link against those. Would that be acceptable to people? Regards, Philip. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
