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

On Wed, Aug 27, 2014 at 12:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I 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.
>
>> I'd like to consider such a thing, but it seems like utter pie in the
>> sky.
>
> On further thought: the existing postmaster log is primarily an error log,
> and for the reasons I mentioned, it seems useless to imagine filtering it
> on security-based grounds. You can either route it to /dev/null or
> restrict viewing to suitably privileged people; there is no middle ground
> with any usefulness.
>
> However: for some values of "audit" it seems like an audit log could
> consist of reports of changes actually applied to the database. If that's
> your definition then it's surely possible to imagine omitting particular
> columns (or rows) from the output, because we've already eliminated all
> the cases where the system couldn't make sense of the input it was fed.
> So I think Alvaro was right to suggest that maybe the logical-decoding
> subsystem, rather than the existing logging subsystem, is where to look
> for solutions. You could do logical decoding of changes and emit a
> filtered version of that to some output that's independent of the current
> postmaster logging arrangements.

There is a case where read query not generating WAL needs to be audited
(e.g., a user might want to audit any queries accessing the table which
contains credit card number). So I doubt if logical decoding is really good
answer for the audit.

Regards,

--
Fujii Masao