Re: Practical impediment to supporting multiple SSL libraries

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Practical impediment to supporting multiple SSL libraries
Дата
Msg-id 87vetcfcbq.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Practical impediment to supporting multiple SSL libraries  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Practical impediment to supporting multiple SSL libraries
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: OS cached buffers (was: Support Parallel Query Execution
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Practical impediment to supporting multiple SSL libraries