Proposed cleanup of libpq's use of stderr

I've been thinking about changing the libpq library to reduce and
centralize its dependence on printing messages to stderr. This
seems like a good idea on general principles, and it will be vital
if people want to run PostgreSQL clients on WIN32 (as Magnus Hagander's
recent patches make possible). On a lot of WIN32 C compilers, output
to stderr goes into the bit-bucket, or causes the app to crash, or
even prevents it from being built in the first place.

There are two separate issues to address. One is the handling of
NOTICE messages from the backend (such as EXPLAIN outputs). libpq
is hardwired to dump these onto stderr. I'm evidently not the first
person to be dissatisfied with that --- fe-exec.c contains

/*
* Should we really be doing this? These notices
* are not important enough for us to presume to
* put them on stderr. Maybe the caller should
* decide whether to put them on stderr or not.
* BJH 96.12.27
*/
fprintf(stderr, "%s", conn->errorMessage);

What I propose we do is invent a callback hook that the application
can set to obtain control when a notice is received. The default
hook function will just print the message to stderr as before, but
applications can override the default to do something else. I suggest
a hook function signature like this

void noticeProcessor (void * arg, const char * message)

and a new libpq accessor function

void PQsetNoticeProcessor (PGconn * conn,
void (*noticeProcessor) (void * arg, const char * message),
void * arg)

The "arg" pointer is saved by PQsetNoticeProcessor and subsequently
passed to the notice processor. This gives a way for the notice
processor to get to any application-dependent state associated with
the connection.

The other issue is that libpq has various internal error messages
that it willy-nilly prints on stderr, rather than handing back to the
application via the PQerrorMessage interface. Some of these can
probably be eliminated or converted into PQerrorMessage returns.
If any remain after a cleanup pass, I'm inclined to invent an
"errorProcessor" hook just like the noticeProcessor hook described
above, so that the application can control what happens to the messages.

Does anyone have any objections or better ideas? None of this will
affect the frontend/backend protocol, it'll just make libpq more
adaptable to frontend environments where writing to stderr isn't a
friendly thing to do.

regards, tom lane