> On Oct 20, 2021, at 10:20 AM, Jeff Davis <pgsql@j-davis.com> wrote:
>
> I'm trying to suggest an approach that is flexible enough (not limited
> to superusers), but also addresses Noah's complaint that ordinary role
> membership should not implicitly control event trigger firing.
>
> The most direct way to address Noah's complaint is to make a new
> explicit user option BYPASS_EVENT_TRIGGERS, which controls whether
> event triggers fire or not.
I'd like to have a much clearer understanding of Noah's complaint first. There are multiple things to consider: (1)
therole which owns the trigger, (2) the role which is performing an action which would cause the trigger to fire, (3)
theset of roles role #1 belongs to, (4) the set of roles role #1 has ADMIN privilege on, (5) the set of roles that role
#2belongs to, and (6) the set of roles that role #2 has ADMIN privilege on. Maybe more?
And that's before we even get into having roles own other roles, which the event trigger patches *do not depend on*.
Inthe patch set associated with this thread, the event trigger stuff is in patches 0014 and 0015. The changes to
CREATEROLEand role ownership are not until patches 0019, 0020, and 0021. (I'm presently writing another set of emails
tosplit this all into four threads/patch sets.)
I'd like to know precisely which combinations of these six things are objectionable, and why. There may be a way
aroundthe objections without needing to create new user options or new privileged roles.
> Another benefit of this is that it makes this event trigger change
> independent of the Role Self-Administration discussion, so it could
> potentially be committed sooner.
I don't think the two are related, though I can understand the confusion. That is, in fact, a small part of why I'm
splittingthe patches into different email threads.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
