Re: Practical impediment to supporting multiple SSL libraries

#1 (**permalink**) 04-12-2008, 02:59 AM

> -----Original Message-----
> From: Martijn van Oosterhout [mailto:kleptog@svana.org]
> Sent: 13 April 2006 09:15
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org; Hiroshi Inoue
> Subject: Re: [HACKERS] Practical impediment to supporting
> multiple SSL libraries
>
> On Thu, Apr 13, 2006 at 08:48:54AM +0100, Dave Page wrote:
> > Well, we had a pure custom implementation of the protocol,
> had a pure
> > libpq based version and after much discussion decided that the best
> > version of all was the hybrid as it allowed us to hijack
> features like
> > SSL, Kerberos, pgpass et al, yet not be constrained by the
> limitations
> > of libpq, or copy query results about so much.
>
> Right. Would you see value in a more formal libpq "hijack-me"
> interface that would support making the initial connection
> and then handing off the rest to something else?
>
> I'm wondering because obviously with the current setup, if
> libpq is compiled with SSL support, psqlODBC must also be.
> Are there any points where you have to fight libpq over
> control of the socket?
>
> I'm thinking that such an interface would need to provide the
> following:
>
> read (sync/async)
> write (sync/async)
> getfd (for select/poll)
> ispending (is there stuff to do)
> release (for when you're finished)
>
> Is there anything else you might need?

I'll have to let Hiroshi comment on that as he wrote the code. I've only
skimmed over it a few times so far.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode