Re: [HACKERS] thread-safe libpq and DBD::Pg
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] thread-safe libpq and DBD::Pg |
Дата | |
Msg-id | 4563.902703709@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] thread-safe libpq and DBD::Pg (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] thread-safe libpq and DBD::Pg
|
Список | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.us> writes: > php3 uses PQoidStatus, so I can imagine great problems if we change the > libpq interface. I am afraid we are stuck with char*. Yeah, I can't really see breaking applications just for a marginal improvement in cleanliness. There is a possible compromise however: we could leave PQcmdTuples and PQoidStatus defined as-is (but do something to get rid of PQoidStatus' use of a static return area), and add two more functions that have more reasonable return conventions. The documentation could describe the older functions as deprecated. Perhaps the int-returning forms could be named "PQCmdTuples" and "PQOidStatus" (note difference in capitalization) ... unless someone has a better idea. Does anyone think this is worth the trouble, or shall we leave bad enough alone? I do intend to get rid of the static return area for PQoidStatus in any case. I'd also like to fix the problem with PQconninfoOptions not being treated as a constant (specifically, the "val" fields are being used as working storage). Is anyone aware of any applications that would be broken by removing "val" from the PQconninfoOption struct? regards, tom lane
В списке pgsql-hackers по дате отправления: