On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
> Looking at pgaudit and the other approaches to auditing which have been
> developed (eg: applications which sit in front of PG and essentially
> have to reimplement large bits of PG to then audit the commands sent
> before passing them to PG, or hacks which try to make sense out of log
> files full of SQL statements) make it quite clear, in my view, that
> attempts to bolt-on auditing to PG result in a poorer solution, from a
> technical perspective, than what this project is known for and capable
> of. To make true progress towards that, however, we need to get past
> the thinking that auditing doesn't need to be in-core or that it should
> be a second-class citizen feature or that we don't need it in PG.
Coming in late here, but the discussion around how to maintain the
auditing code seems very similar to how to handle the logical
replication of DDL commands. First, have we looked into hooking
auditing into scanning logical replication contents, and second, how are
we handling the logical replication of DDL and could we use the same
approach for auditing?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +