Libpq functions

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.

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.

regards, tom lane

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

Magnus Hagander <mha@sollentuna.net> writes:

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.

Ah. Now that you mention it, I recall someone bringing up that exact
issue last summer on the hackers list. Was that you? If not, you might
want to go digging in the list archives (I forget what was said...)

regards, tom lane

On Saturday, January 09, 1999 11:13 PM, Tom Lane [SMTP:tgl@sss.pgh.pa.us]
wrote:

Magnus Hagander <mha@sollentuna.net> writes:

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.

Ah. Now that you mention it, I recall someone bringing up that exact
issue last summer on the hackers list. Was that you? If not, you might
want to go digging in the list archives (I forget what was said...)

Could've been me. I'll go check to be sure.
I remember fighting this same obstacle in the frontend library before you
fixed it - because Win32 does not handle fdopen() on sockets.

Also, I noticed that in backend/util/error/elog.c, it checks for "Pfout !=
NULL" to see if it's running under the postmaster. If Pfout == NULL, it
sends its data out to stderr instead of the client.
Shouldn't it be safe to just if on the global "IsUnderPostmaster" boolean
here? Or am I missing something? (I'm starting my work by trying to get rid
of anything other than pqcomm.c using Pfout and Pfin).

//Magnus

Also, I noticed that in backend/util/error/elog.c, it checks for "Pfout !=
NULL" to see if it's running under the postmaster. If Pfout == NULL, it
sends its data out to stderr instead of the client.
Shouldn't it be safe to just if on the global "IsUnderPostmaster" boolean
here? Or am I missing something? (I'm starting my work by trying to get rid
of anything other than pqcomm.c using Pfout and Pfin).

Not sure, but it is possible the coder didn't know about the variable.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026