Re: [INTERFACES] Re: thread-safe libpq and DBD::Pg

Eric Marsden <emarsden(at)mail(dot)dotcom(dot)fr> writes:
>>>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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