From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
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, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> |
Subject: | Re: Practical impediment to supporting multiple SSL libraries |
Date: | 2006-04-14 15:22:23 |
Message-ID: | 9447.1145028143@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-04-14 15:23:44 | Re: Practical impediment to supporting multiple SSL libraries |
Previous Message | Tom Lane | 2006-04-14 15:10:34 | Re: Control File |