Re: Similar to csvlog but not really, json logs?

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Consider an audit system where which columns end up in the audit log are
> > controlled by issuing ALTER TABLE .. ALTER COLUMN type statements.
>
> <blink>
>
> I'd like to consider such a thing, but it seems like utter pie in the
> sky. Do you really believe that elog() could know enough about what it's
> printing to apply such a filter? Do you think elog() should be allowed
> to do catalog accesses in order to find out what the filter conditions
> should be (hint: no)? Perhaps you think that we don't ever need to emit
> error messages before we've analyzed a query enough to figure out which
> tables are involved? Let alone which columns? Let alone which literals
> elsewhere in the query string might be somehow associated with those
> columns?

I wasn't intending to suggest that this would be handled by elog()
directly, no.

I agree that we're going to need to separate auditing and filtering from
elog. Perhaps that means it was the wrong context in which to bring up
these questions about alternative log output formats, but I'd like to
avoid having a *completely* independent system from the logging
infrastructure, if possible.

The pgaudit system is an example of how this could be done independently
but there's some serious limitations there.

For the elog piece, we'd mainly need to figure out how to get it to log
useful information when there are *serious* problems (think PANIC and
the like) but not to leak information (do I care that someone typo'd the
INSERT command and produced an ERROR? no.. or if I do, could I at
least have it just log "ERROR: INSERT (parse error)" or something?).
It's certainly never going to have the smarts to figure out that
characters 16-32 of this malformed INSERT statement shouldn't be logged.

Thanks,

Stephen