Re: [HACKERS] Libpq functions
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Libpq functions |
Дата | |
Msg-id | 29237.915671812@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Libpq functions (Magnus Hagander <mha@sollentuna.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: