Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] some more rambling on the new fe/be communication

From: Brett McCormick <brett(at)work(dot)chicken(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] some more rambling on the new fe/be communication
Date: 1998-06-04 23:17:33
Message-ID: 13687.11021.415683.35119@web0.speakeasy.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 4 June 1998, at 19:10:09, Tom Lane wrote:

> > I am tempted to hold off on that once I get my current
> > SSL up to snuff and instead work on perl stored procedures, as I feel
> > that is more valuable (and will also do more to familiarize myself
> > with the code).
> 
> I'd recommend you do the 6.4 version of the patch first, while it's
> still fresh in your mind.  AFAIK, stored procedures are a completely
> different area of the system; you won't learn anything there that is
> relevant to the FE/BE protocol.

I know -- I'm looking to learn more about other areas of the system.
And because the perl stored procedures will support lots of cool
backend functions (what sort of stuff is permissible to interface to?)
i'll learn about them that way.

I've learned as much about the fe/be protocol as I wish to know ;)
But I may take your advice.

> > I'm sure an SSL connection can be select()'d, and it does support
> > non-blocking recv (I think that's the only way).  I think it does
> > block, however, if it doesn't get a full SSL "packet" (or whatever the
> > appropriate term may be).
> 
> Hmm ... I don't know enough about SSL to know if this is really a
> problem, but your comment raises warning flags in my head.  This
> needs investigation.

Unfortunately, SSL documention is rather incomplete.

thanks for your info, comments and suggestions

In response to

pgsql-hackers by date

Next:From: Chris OlivierDate: 1998-06-04 23:25:06
Subject: (no subject)
Previous:From: Tom LaneDate: 1998-06-04 23:10:09
Subject: Re: [HACKERS] some more rambling on the new fe/be communication

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group