Re: Practical impediment to supporting multiple SSL libraries

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

In response to

Responses

Browse pgsql-hackers by date

  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