Re: pgaudit - an auditing extension for PostgreSQL - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: pgaudit - an auditing extension for PostgreSQL
Date
Msg-id 20140502182223.GX2556@tamriel.snowman.net
Whole thread Raw
In response to Re: pgaudit - an auditing extension for PostgreSQL  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pgaudit - an auditing extension for PostgreSQL
Re: pgaudit - an auditing extension for PostgreSQL
List pgsql-hackers
* Josh Berkus (josh@agliodbs.com) wrote:
> Logging hooks.  We really need some contrib/ modules which take
> advantage of these.

I'm aware and I really am not convinced that pushing all of this to
contrib modules using the hooks is the right approach- for one thing, it
certainly doesn't seem to me that we've actually gotten a lot of
traction from people to actually make use of them and keep them updated.
We've had many of those hooks for quite a while.

What 2Q has done here is great, but they also point out problems with
building this as a contrib module using the hooks.  As we add more
capabilities and improve the overall PG system (new objects, etc), I'm
rather unconvinced that having to go, independently, update the contrib
modules to understand each new object is going to be a terribly workable
long-term solution.

Additionally, using triggers (either on the tables or the event
triggers), while good for many use-cases, doesn't completely answer the
auditing requirements (SELECT being the great example, but there are
others) and having to combine event triggers with various hooks just
doesn't strike me as a great design.  (I don't intend to knock what 2Q
has done here at all- they're using a minimal-backend-hacking approach,
and under that constraint they've done exactly what makes sense).
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Supporting multiple column assignment in UPDATE (9.5 project)
Next
From: Hadi Moshayedi
Date:
Subject: Faster array_length()