Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg
От | Tom Lane |
---|---|
Тема | Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg |
Дата | |
Msg-id | 3988.902932395@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg (Eric Marsden <emarsden@mail.dotcom.fr>) |
Список | pgsql-interfaces |
Eric Marsden <emarsden@mail.dotcom.fr> writes: >>>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes: TL> I think I remember someone speculating about writing a pure Tcl TL> front end by programming directly to the socket-level FE/BE interface, TL> but I haven't heard about any results. > Can the FE/BE interface be expected to remain stable over time? As > much so as libpq? Well, we changed it significantly for 6.4, so I wouldn't care to promise it'll never change again. BUT: thanks to the fact that the client sends a protocol version number at the start of a session, the server can and does support old-protocol clients. So piecemeal updates of client libraries seem feasible. I'd be a lot more worried about proliferating clients that know the wire-level protocol if this were not so. It occurs to me that there is a potential versioning bug in the way libpq deals with this issue: it sends out the version number with sp.protoVersion = (ProtocolVersion) htonl(PG_PROTOCOL_LATEST); But PG_PROTOCOL_LATEST is defined (in some backend include file or other) as the latest protocol version supported by the *server*. Thus, merely recompiling libpq against source files of an updated server will cause it to claim that it speaks the latest protocol version, whether or not you've actually touched libpq. This is bogus. I think libpq needs to have its *own* constant defining what protocol version number it speaks, which you'd have to update manually whenever you change libpq to handle a different version. Of course, the same goes for any other client library that deals with the wire protocol directly. regards, tom lane
В списке pgsql-interfaces по дате отправления: