Re: Practical impediment to supporting multiple SSL libraries

-----Original Message-----
From: "Tom Lane"<tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: 14/04/06 16:22:45
To: "Martijn van Oosterhout"<kleptog(at)svana(dot)org>
Cc: "Greg Stark"<gsstark(at)mit(dot)edu>, "Zeugswetter Andreas DCP SD"<ZeugswetterA(at)spardat(dot)at>, "Dave Page"<dpage(at)vale-housing(dot)co(dot)uk>, "pgsql-hackers(at)postgresql(dot)org"<pgsql-hackers(at)postgresql(dot)org>, "Hiroshi Inoue"<inoue(at)tpf(dot)co(dot)jp>
Subject: Re: [HACKERS] Practical impediment to supporting multiple SSL libraries

> A fair question to ask is whether psqlODBC would consider
> going back to a non-hybrid implementation if these features did exist
> in libpq.

It's not something I want to spend any more time on, and Hiroshi made it quite clear on -odbc yesterday that he doesn't want libpq to become a requirement of psqlODBC (it's dynamically loaded atm, thus is optional).

Regards, Dave

-----Unmodified Original Message-----
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Fri, Apr 14, 2006 at 10:42:33AM -0400, Greg Stark wrote:
>> As long as there's a defined wire protocol (and there will always be
>> one) then there's nothing wrong with what the psqlODBC driver is doing

> Well, the main motivation for this is that when a new version of the
> protocol appears, libpq will support it but psqlODBC won't. If libpq
> provides a way to get these small bits of the unparsed stream in a
> protocol independant way, then that problem goes away.

Greg's observation is correct, so maybe we are overthinking this
problem. A fair question to ask is whether psqlODBC would consider
going back to a non-hybrid implementation if these features did exist
in libpq.

> There are a number of other (primarily driver) projects that would
> benefit from being able to bypass the PGresult structure for storing
> data.

Please mention some specific examples. We need some examples as a
reality check.

regards, tom lane