On Thursday, January 07, 1999 2:17 AM, Tom Lane [SMTP:tgl@sss.pgh.pa.us]
wrote:
> Magnus Hagander <mha@sollentuna.net> writes:
> > [ Why is the server-side libpq so crufty? ]
>
> Apparently, that set of files was once used for both the frontend and
> backend sides of the FE/BE protocol. It no longer is, but no one has
> gotten around to ripping out the now-dead parts of the code, nor to
> fixing the comments.
>
> I didn't bother to touch it when I rewrote the client-side libpq last
> summer, because there wasn't any functional improvement to be had there.
> It pretty much does everything the backend needs done.
>
> If you have the time and energy to clean it up just in the name of
> code beautification, step right up :-). One thing that would be good
> right off the bat is to change the name --- I think it's confusing to
> call both the FE and BE modules libpq, when they are no longer the same
> code or even very close.
I guess I shouldn't have said anything :-)
I'll see if I can shake loose the time to look at it. I might have to,
though.
> > Finally - is there any special reason that the backend still uses the
(FILE
> > *) method to talk to the clients? Using the global Pfout and Pfin
variables?
> > Wouldn't it be better to be consistent and use the same functions as in
the
> > revised frontent library?
>
> The main reason for rewriting the front end was to satisfy clients that
> didn't want to block while awaiting backend I/O. The backend doesn't
> have any comparable requirement: when it's waiting for the frontend, it
> has nothing better to do (AFAIK anyway). And using stdio does have its
> advantages in simplicity and just plain standard-ness. So I doubt it's
> worth making that kind of change.
Well, I see one reason to change it. Which is why I came up with the
question in the first place. I was looking at the possibility of putting SSL
on top of libpq. I have a project I'm working on that needs to transmit
"lightly sensitive data" across the internet. Right now using SSH
forwardings, but that's not exactly the "ideal solution".
Anyway, SSLeay has functions that replace read() and write(), but nothing to
work with FILE *:s.
So if there are no major objections, I might take a shot at changing it to
working directly on the socket, and put SSLeay on it.
A quick check shows that the "copy" command goes out of its way to break the
abstraction of "backend libpq". Takes a copy of the Pfin and Pfout FILE*:s
and writes directly to them. Darn. This might take more time than I first
thought... :-(
//Magnus
