Re: Patch review for logging hooks (CF 2012-01)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 5, 2012 at 12:50 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> I'd like to see a spec for exactly which fields of ErrorData the hook is
>>> allowed to change, and some rationale.

>> Good question. I'd somewhat be inclined to say that it should only be able
>> to change output_to_server and output_to_client, and possibly only to change
>> them from true to false (i.e. I'm not sure the hook should be able to induce
>> more verbose logging.) But maybe that's too restrictive. I doubt we can
>> enforce good behaviour, though, only state that if you break things you get
>> to keep all the pieces.

The reason it can't sensibly expect to change them from off to on is
that control will never get here in the first place if they're both off.
That is a feature not a bug: the ereport mechanisms are designed to skip
most of the message-construction work for messages that are so low
priority that they're not going to get printed anywhere. If we wanted
the hook to be able to override that, it would have to be called from
errstart and it would then have much less information to work with.

> It sort of looks like it's intended to apply only to server output, so
> I'd find it odd to say that it should be able to mess with
> output_to_client.

OK, so let's document that the only supported change in ErrorData is to
turn output_to_server from on to off. I can see how that constitutes
a potential feature: the hook might be intended as a filter that allows
logging or not logging according to some rule not supported by the core
system. You'd have to ensure that log_min_messages is set low enough
for all desired messages to get generated in the first place, but then
the hook could control things beyond that. I can also imagine a hook
that's meant as some sort of aggregator, so that it would accumulate a
summary form of messages that it then told the core not to print.

regards, tom lane