Re: audit table containing Select statements submitted

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'.

The user could just set up log_line_prefix as an XML attribute string. 
So we'd have something like:
 <pglog level="LOG" user="andrew" dbname="blurfl">|<![CDATA[|  
statement: select count(*) from foo where a < b ; |]]></pglog>|


Now, what were you saying about sponsorship? ;-)

cheers

andrew