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

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.

regards, tom lane