| From: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Meskes <meskes(at)postgreSQL(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [HACKERS] library policy question |
| Date: | 2000-03-07 16:57:50 |
| Message-ID: | 38C5350E.A76F705E@wgcr.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> 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".
> 7.0 would be a good time to do that if we were gonna do it. Comments?
If time is available to do that, I agree that now is an great time to do
so. As a user of a multithreaded web front end to PostgreSQL
(AOLserver), I personally am affected by the result. The AOLserver
PostgreSQL driver avoids the PQconnectdb() issue by using
PQsetdbLogin().
HOWEVER, it was a hunt to find that information -- it would have been
nice for the docs to say 'libpq {is|is not} threadsafe' -- even 'libpq
is threadsafe if and only if the following API calls are used:' would be
nice.
In fact, even if libpq is not touched, a documentation note to libpq's
threadsafeness would be nice.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-03-07 17:01:29 | Re: [HACKERS] alter_table.sql |
| Previous Message | Thomas Lockhart | 2000-03-07 16:57:45 | Re: [HACKERS] library policy question |