Re: [HACKERS] libpq questions...when threads collide
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] libpq questions...when threads collide |
Дата | |
Msg-id | 3.0.1.32.19991212145313.0104edb0@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] libpq questions...when threads collide (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] libpq questions...when threads collide
|
Список | pgsql-hackers |
At 05:41 PM 12/12/99 -0500, Tom Lane wrote: >Don Baccus <dhogaza@pacifier.com> writes: >> Despite the thread unsafeness >> of PQsetdb et al, I've never seen a failure in this environment >> and I've never heard of folks experiencing such a failure. > >The *only* thing that's actually thread-unsafe, AFAIR, is >PQconnectdb's use of a global array for connection parameters. >PQsetdb/setdbLogin are thread-safe; so just use them instead. Cool! I am using setdbLogin but the documentation sez they, too, aren't threadsafe...maybe this should be changed? This is great news. >At least that was true before the async-connection code got added. >I haven't looked at that to see if it introduces any problems. For the moment, I'm happy to believe that it hasn't, it makes my immediate future much simpler if I do so... Also, the documentation describes two routines, PQoidStatus and PQoidValue, but the libpq source seem to only define PQoidStatus. (some user asked for a routine to feed back the oid of an insert, so I looked into it while simultaneously suggesting he study "sequence" and its associated "nextval" and "currval" functions and ponder on why it's really a bad idea to related tables by storing oids rather than generated keys) - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: