On Fri, May 12, 2006 at 02:43:56PM -0400, Andrew Dunstan wrote:
> Josh Berkus wrote:
> >Andrew,
> >
> >
> >>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.
> >>
> >
> >Hmmm ... I don't see this as a problem. Just stick the whole message into
> >a single XML field. This is one area where XML is easier that SQL; since
> >it's a document format, it has no problem with a great big blob of text.
> >"Unstructured Data" and all that nonsense.
> >
> >Then whatever utility the user uses to *read* the XML can parse the
> >message according to the user's desires. It'll still be an improvement
> >over the current format for log digestion, since it will become easy to
> >separate the message from the prefix and tag (which currently it's not).
> >
> >The only real issue I see is the possibility of XML codes embedded in the
> >text, but that seems minor.
> >
> >
> well, we could either XML escape the message or put it in a CDATA block.
> The latter would be arguably more humanly readable.
>
> Given that, I think we could get away with a single GUC var to govern
> this, log_format with possible values (to start with, at least) of
> 'plain' and 'xml'.
I'm wondering if there would be value in allowing for a second, seperate
log stream...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461