I wrote: > Stephen Frost <sfr...@snowman.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers