-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
(yes, I'm going through old emails tonight) > Spinning off into the off-topic based on the question - if you do > this, please make it *optional*. Unless you plan to actually implement > all the libpq functionality and also shoulder the burden to release a > new version whenever a new version of libpq is out. Things like > kerberos/gssapi and cert authentication that actually work the same > way as others... Er, no, it certainly will not be optional, that kind of ruins the point. But yes, we will certainly not remove any functionality and keep up with any libpq changes. Not sure why you would think a new version would be released when a new version of libpq is released - currently we are linked to any old random libpq that happens to be on the user's box, and it almost always is not the latest one. :) Once this is in place, I expect we'll be making changes that will be picked up *by* libpq, because it frankly hasn't seen much love lately. > Might be worth looking at what the ODBC folks did though - they run > the actual protocol for the queries, but they use libipq for > connection setup and authentication (if found - they'll fallback on > doing simple auth etc if libpq isn't there) Yeah, we might end up doing something like that, but it seems easier from this distance to simply subsume a good copy of libpq into the DBD::Pg tree. Thanks for the feedback and idea. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201102082203 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1SBEEACgkQvJuQZxSWSsiZcwCg7nRBwTnQ9bmVUMPXtk3cZShV 70sAnijn2nbWaRVMgljnKz4mqZDqVklk =m89q -----END PGP SIGNATURE----- -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs