[After a discussion on IRC with Stephen…]
At 2015-01-20 21:47:02 -0500, sfrost@snowman.net wrote:
>
> Review the opening of this email though and consider that we could
> look at "what privileges has the audit role granted to the current
> role?" as defining what is to be audited.
Right, I understand now how that would work. I'll try to find time to
(a) implement this, (b) remove the backwards-compatibility code, and
(c) split up the USE_DEPARSE_FUNCTIONS stuff.
> > For example, what if I want to see all the tables created and
> > dropped by a particular user?
>
> I hadn't been intending to address that with this scheme, but I think
> we have that by looking for privilege grants where the audit role is
> the grantee and the role-to-be-audited the grantor.
For CREATE, yes, with a bit of extra ACL-checking code in the utility
hook; but I don't think we'll get very far without the ability to log
ALTER/DROP too. :-) So there has to be some alternative mechanism for
that, and I'm hoping Robert (or anyone!) has something in mind.
> Well, I was primairly digging for someone to say "yes, the object
> access stuff will be reworked to be based on event triggers, thus
> removing the need for the object access bits".
(This doesn't entirely make sense to me, but it's tangential anyway, so
I won't comment on it for now.)
-- Abhijit