Thread: Libpq functions

Hi!

I was just poking around a bit in the libpq (server side this time) files,
and noticed a few things.

For example, the StreamOpen() function is defined there (pqcomm.c), but it
is _never_ used (at least as far as I can see). Is there any reason for it
being there? Or is it some old function that is no longer used? Looks to me
like a function that is only used on the client-side?

Also, the comments on top of pqcomm.c names several functions that do not
exist (such as pq_accept). They are commented as being used in both the
backend and the frontend - but I don't beleive the file is linked into the
libpq frontend any more?

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?



//Magnus

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