Proposal: new ereport option "errdetail_log"

I'm not sure how many people noticed this -patches discussion:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00282.php
so I'm reposting on -hackers.

The conclusion I drew from that thread is that we should send the text
of all queries involved in a deadlock to the server log, regardless
of session ownership, while reverting the client-side display to what
it's been historically. We could argue separately about whether it's
ever really safe to report other-session queries, but in any case the
server log will receive a more complete report in general. To implement
that we'll need some new feature in elog.c. I propose a new auxiliary
function "errdetail_log()" that works exactly like errdetail(), except
that the string it produces is reported only to the server log, never
to the client. If both errdetail() and errdetail_log() are used then
one string goes to the client and the other to the log. The current
uses for this are in deadlock reporting and in reporting what objects
a user owns when DROP USER fails.

The main objection I can think of to this approach is that the two
strings will be somewhat redundant, and storing both independently could
result in an out-of-memory failure that otherwise wouldn't occur. I'm
not too worried about that in the deadlock case, because it's unlikely
that you'd have a large number of processes involved in a deadlock,
so the duplicative storage of "Process N is blocked by process M" lines
really isn't going to amount to much. There's a bit more space at stake
in the DROP USER case, but it's still pretty small (since the whole
point in the DROP USER case is to limit how much text goes to the
client) and in any case I don't foresee people doing DROP USER in
low-memory situations. So, while we could arrange the definition in
some more complex way to avoid storing duplicate text, I don't really
think it's worth the trouble and potential loss of flexibility.

Barring objections, I'm going to go ahead and do this now so that we can
close the books on Itagaki-san's deadlock reporting patch. I don't want
to risk forgetting that we have a security concern to deal with there.

regards, tom lane