Auditing extension for PostgreSQL (Take 2)

I've posted a couple of messages over the last few weeks about the work
I've been doing on the pg_audit extension. The lack of response could
be due to either universal acclaim or complete apathy, but in any case I
think this is a very important topic so I want to give it another try.

I've extensively reworked the code that was originally submitted by
2ndQuandrant. This is not an indictment of their work, but rather an
attempt to redress concerns that were expressed by members of the
community. I've used core functions to determine how audit events
should be classified and simplified and tightened the code wherever
possible. I've removed deparse and event triggers and opted for methods
that rely only on existing hooks. In my last message I provided
numerous examples of configuration, usage, and output which I hoped
would alleviate concerns of complexity. I've also written a ton of unit
tests to make sure that the code works as expected.

Auditing has been a concern everywhere I've used or introduced
PostgreSQL. Over time I've developed a reasonably comprehensive (but
complex) system of triggers, tables and functions to provide auditing
for customers. While this has addressed most requirements, there are
always questions of auditing aborted transactions, DDL changes,
configurability, etc. which I have been unable to satisfy.

There has been some discussion of whether or not this module needs to be
in contrib. One reason customers trust contrib is that the modules are
assumed to be held to a higher standard than code found on GitHub. This
has already been pointed out. But I believe another important reason is
that they know packages will be made available for a variety of
platforms, and bugs are more likely to be experienced by many users and
not just a few (or one). For this reason my policy is not to run
custom-compiled code in production. This is especially true for
something as mission critical as a relational database.

I realize this is not an ideal solution. Everybody (including me) wants
something that is in core with real policies and more options. It's
something that I am personally really eager to work on. But the reality
is that's not going to happen for 9.5 and probably not for 9.6 either.
Meanwhile, I believe the lack of some form of auditing is harming
adoption of PostgreSQL, especially in the financial and government sectors.

The patch I've attached satisfies the requirements that I've had from
customers in the past. I'm confident that if it gets out into the wild
it will bring all kinds of criticism and comments which will be valuable
in designing a robust in-core solution.

I'm submitting this patch to the Commitfest. I'll do everything I can
to address the concerns of the community and I'm happy to provide more
examples as needed. I'm hoping the sgml docs I've provided with the
patch will cover any questions, but of course feedback is always
appreciated.

--
- David Steele
david(at)pgmasters(dot)net