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@github.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:
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. --
