backend/frontend communication

I'm rewriting my SSL for patch so it's a little less messy, and I've
come across something interesting.

What I've done is replaced Pfin,Pfout and Pfdebug with a struct called
PGcomm.

pqcomm.c had Pfin/Pfout/Pfdebug as "global" variables.  some other c
files have "extern" entries for these variables.  the in/out funcs in
pqcomprim.c take a FILE * as an argument instead of the extern
approach.  I'm not sure there are any cases where the FILE * passed
differs from the one in the global Pfin, but to maintain consistency,
I haven't changed it.  So the functions in pqcomm.c still access the
global copy of the PGcomm struct (my replacement for
Pfin/Pfout/Pfdebug) and pqcomprim.c still takes a PGcomm * as an
argument.  There are actually little [f]read/[f]write system calls in
pqcomm.c, most of the communication takes place by calling pqcomprim.c
functions.

the reason i'm writing this mail are twofold, one is: are the
developers interested in merging my input/output changes into the
distribution.  this has the benefit of making the io a little more
coherent, right now it seems sort of patched together, read/write
mixed with fread/fwrite, functions that do the same thing but take
different arguments, fread/fwrite in the actual code instead of
calling an appropriate function.  this seems like a good idea to me.
we could also define an interface for implementing transport layers,
so my patch could be an add-on module.

so, the interesting part is this: there is a call to pq_putstr after
the client has disconnected.  so, when I exit out of psql, I get an
error (with my patch) whereas before, if fputs gets a NULL pointer, it
doesn't signal an error for some reason.  I've modified my patch to
match the behavoir, but it does seem a little odd.  I will try to find
the place this is being called from, as it does not seem like a good
thing.

Let me know if I need to clarify.