Problems with extended-Query logging code

I happened to notice that the recently added code to log Bind-message
parameters was printing garbage into my log. On investigation it turned
out to be trying to print an already-pfree'd string. That's fixable,
but having looked at the code closely, I see a bunch of other stuff I'm
not happy about either:
* It's overly verbose: printing the same parameters twice seems
excessive.
* It's inefficient: it's spending effort on formatting and copying
parameter information around, whether or not there's any chance of
that information ever being wanted.
* It doesn't log the values of parameters sent in binary mode, which
is something that at least JDBC needs.

Another issue, which isn't the fault of the recent patches but has been
there right along, is that execution of Parse or Bind could take awhile
(due to planning of a complex query) but there's no log_duration or
log_min_duration_statement coverage for these message types.

Here are some thoughts about fixing it:

* For extended-Query mode I propose that we treat log_duration and
log_min_duration_statement as being effectively per-message not
per-statement. That is, we'd log a Parse or Bind operation if it
individually exceeded the duration threshold, and not otherwise.

* I'm inclined to think that Parse and Bind shouldn't be logged at all,
or maybe only at DEBUG2 or higher, unless logged by duration logging.
If we've got support for logging the statement text and the parameter
values at Execute time, isn't logging the preliminary steps just
bloating the log?

* I think that the best way to log bind-parameter values is to run the
datatype output functions on the saved parameter values. This works
whether they were sent in text or binary mode, and avoids any extra
overhead at Bind time that might not be repaid.

Comments?

regards, tom lane