> On Nov 1, 2021, at 1:13 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
>> Having Batman *own* all residents in Gotham city would work, if we can agree on a role ownership system. It has the
downsidethat only a role's (direct or indirect) owner can do the auditing, though. That's more flexible than what we
havetoday, where only superuser can do it, but maybe some people would want to argue for a different solution with even
moreflexibility? A grantable privilege perhaps? But whatever it is, the reasoning about who gets audited and who does
notmust be clear enough that Batman can pass a compliance audit.
>
> What about roles which Batman owns but which he *doesn't* want the event
> trigger to fire for?
I think Batman just has the event trigger exit early for that. There is nothing we can hardcode for filtering users
intoand out of the trigger that will be as flexible as the logic that Batman can implement in the trigger itself. We
onlyneed to worry about Batman over stepping his authority. It's not our job to filter further than that.
> Note that event triggers are not strictly limited to the auditing case.
> Viewing them through that lense masks other quite common use-cases which
> are also importnat to consider (like preventing many users, but not all,
> from being able to DROP objects as a clear example).
Nothing in my proposal limits what superusers can do with event triggers they create. The issue under discussion is
entirelyto do with what non-superusers are allowed to do with event triggers. I see no reason why some ordinary role
"joe"should be allowed to thwart DROP commands issued on a table that "joe" doesn't own by roles that "joe" doesn't
own. Maybe "own" here should be "have ADMIN on", but it has to be something.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company