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