Re: Let's use libpq for everything

On Tue, Nov 4, 2014 at 2:22 AM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
wrote:

> In the long-term, I believe psqlodbc would be better off relying on libpq
> for all operations, and not touching the socket directly. That would allow
> getting rid of all the authentication stuff, and a lot of other code. In
> general, less code to maintain is good. This also ties into my recent work
> in the PostgreSQL and libpq side to support other SSL implementations than
> OpenSSL. If we ever get to do that in PostgreSQL, psqlodbc will still be
> stuck with OpenSSL until someone gets around to adding support for the new
> libraries. If we pull that off in PostgreSQL side, *and* switch to doing
> everything through libpq in psqlodbc, we have a lot to gain: if we can
> replace OpenSSL with native Windows calls, we would no longer need to ship
> OpenSSL with the installer, and we would no longer be vulnerable to
> whatever security issues OpenSSL happens to have that week.
>
+1.

> I went ahead and replaced all the backend-interactions with libpq calls.
> I've pushed that to a development branch at: git(at)github(dot)com:hlinnaka/psqlodbc.git,
> branch "libpq-integration4". It's not 100% complete - a few regression
> tests are failing - but it mostly works. Not surprisingly, this makes a lot
> of code unnecessary:
>
> 46 files changed, 1357 insertions(+), 7545 deletions(-)
>
Ugh. That's... Neat.

> The principle is simple: instead of sending FE/BE protocol messages
> directly, just call the corresponding libpq functions. There are a few
> problems that are worth mentioning:
> [...]
> Does anyone object to this as a goal?
>
Reducing the number of extra dependencies that pgodbc has is definitely
worth it. People have complained many times in the past that the msi
installer bundles vulnerable versions of SSL... And this increases the work
of maintainers.
--
Michael