Re: Practical impediment to supporting multiple SSL libraries - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Practical impediment to supporting multiple SSL libraries
Date
Msg-id 87vetcfcbq.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Practical impediment to supporting multiple SSL libraries  (Greg Stark <gsstark@mit.edu>)
Responses Re: Practical impediment to supporting multiple SSL libraries  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Greg Stark <gsstark@MIT.EDU> writes:

> "Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> writes:
> 
> > > Well, the psqlODBC driver apparently ran into a number of problems with
> > > libpq that resulted in them not using it for their purpose. Given libpq
> > > primary purpose is to connect to PostgreSQL, it failing at that is
> > > something that should be fixed.
> > 
> > I think you are forgetting, that e.g. a JDBC driver will not want to depend
> > on an external C dll at all. It will want a native Java implementation
> > (Group 4). Thus imho it is necessary to have a defined wire protocol, which
> > we have.
> 
> I think you are forgetting that this is a complete nonsequitor. 

Hm, now that I've had some sleep I think I see where you're going with this.

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 and having a
libpq mode that hands off small bits of the unparsed stream isn't really any
different than just having the driver read the unparsed data from the socket.

I'm not sure whether that's true or not but it's certainly a reasonable point.
Sorry for my quick response last night.


-- 
greg



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: OS cached buffers (was: Support Parallel Query Execution
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Practical impediment to supporting multiple SSL libraries