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.