On Wed, Jan 21, 2015 at 1:42 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
> At 2015-01-20 20:36:39 -0500, robertmhaas@gmail.com wrote:
>> I think this is throwing the baby out with the bathwater. Neither C
>> functions nor all-or-nothing are going to be of any practical use.
>
> Do you see some approach that has a realistic chance of making 9.5 and
> would also actually be worth putting into 9.5? Suggestions very welcome.
Well, I'm still of the view that there's little to lose by having this
remain out-of-core for a release or three. We don't really all agree
on what we want, and non-core code can evolve a lot faster than core
code, so what's the rush?
I'm coming around to the view that we're going to need fairly deep
integration to make this work nicely. It seems to me that the natural
way of controlling auditing of a table is with table or column options
on that table, but that requires either an extensible reloptions
framework that we don't have today, or that it be in the core server.
Similarly, the nice way of controlling options on a user is some
property attached to the user: audit operations X, Y, Z when performed
by this user.
If you held a gun to my head and said, we must have something this
release, I'd probably go for a GUC with a value that is a
comma-separated list of role:operation:object triplets, like this:
audit_stuff = 'alice:*:*, *:delete:*, bob:*:table secret'
...read as:
- Audit everything alice does.
- Audit all deletes by anyone.
- Audit all access by bob to table secret.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
