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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
