-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
> This seems like a bunch of work for little gain to me. Why not just > patch libpq, perhaps adding a "no protocol 2 branching" compile time > option and the chunking? > > I would also be worried about having the new version lag behind any > libpq enhancements in the future. > > If nothing else, can we at least have DBD::Pg support both the new > library and libpq at build time? These are good questions. Keep in mind this is just an idea, and I've not started any plans to actually move off of libpq at this moment. > This seems like a bunch of work for little gain to me. Why not just > patch libpq, perhaps adding a "no protocol 2 branching" compile time > option and the chunking? Patching libpq is an option, but even if the patches were to be accepted, we would have to wait until the next major release of Postgres came out, and then add a bunch of branching code to DBD::Pg to handle both the old and the new version. And DBD::Pg users would be out of luck unless they were compiling against the latest version of Postgres. Further, things such as chunking the returned results cannot really be emulated in DBD::Pg when using the older libpq versions, so it would be a mess. I'd rather have chunking always be possible with DBD::Pg, regardless of what Postgres version you happen to have available on the box you compiled DBD::Pg on. Another complication is that libpq is a generic C library interface, and while patches we submit might be useful to DBD::Pg, we'd have to keep them generic enough, and justify them, to have them included without pushback. For instance, the 'no protocol 2' option would work for us, as we no longer connect to ancient versions of Postgres, but would not be accepted until all other applications using libpq did the same. > I would also be worried about having the new version lag behind any > libpq enhancements in the future. I'm not worried about this one. As stalled as DBD::Pg development got in the last year, libpq is hardly changing very fast. If we were to roll out own C interface (modelled on libpq: let's not get totally insane), rolling in changes to libpq should be simple enough. > If nothing else, can we at least have DBD::Pg support both the new > library and libpq at build time? There would be little point in that. Any changes made in libpq could not be taken advantage of without code changes to DBD::Pg anyway. Bug fixes might be another matter, but it would be far easier for someone to upgrade DBD::Pg rather than get a new libpq, which would basically require upgrading their version of Postgres. - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200708192102 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFGyOhCvJuQZxSWSsgRAwm8AKCURFumRCdfBFlEHNj0lQqEDBNDCQCdEKhE Qh5o3n2PmEWxA8lZSVulbQs= =8FTt -----END PGP SIGNATURE-----
