Josh Berkus wrote:
>
> Secondly, you can use the log. We've discussed on this list making it
> possible to log in CSV, XML or other database-digestable format.
> Unfortuantely, there doesn't appear to be much momentum behind that; I
> don't know that anyone is writing any code presently. Sponsorship?
>
Well, let's think about it some first, before we line up $$ :-)
We really have 3 bits of the log: the prefix, the tag, and the message.
Turning the prefix into whatever is needed is in the hands of the user.
We could provide a corresponding log_line_suffix to allow XML element
completion if necessary. The tag could likewise easily be XMLized (or
CSVized, or whatever). The real problem is the message, which is now
from the logging code's point of view basically an opaque string.
Changing that would be a massive undertaking, especially when you think
of the effect on the translators. And first we would need to come up
with a set of fields, or several sets of fields, that we wanted to use.
The reason I haven't gone down this road, and just did log_line_prefix,
is that it strikes me as too inflexible. I think postprocessing is
probably a better way to go, and just leave the messages opaque from
postgres' point of view. If someone has a better proposal, let's see an
example of how all the various messages would be handled.
cheers
andrew
