> On Oct 20, 2021, at 10:20 AM, Jeff Davis <pg...@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) the role which owns the trigger, (2) the
role which is performing an action which would cause the trigger to fire, (3)
the set of roles role #1 belongs to, (4) the set of roles role #1 has ADMIN
privilege on, (5) the set of roles that role #2 belongs 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*. In the patch set associated with
this thread, the event trigger stuff is in patches 0014 and 0015. The changes
to CREATEROLE and role ownership are not until patches 0019, 0020, and 0021.
(I'm presently writing another set of emails to split 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 around the 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 splitting the patches into different email
threads.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
