From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Steve Chavez <steve(at)supabase(dot)io> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Allow database owners to CREATE EVENT TRIGGER |
Date: | 2025-05-07 01:36:52 |
Message-ID: | CAKFQuwZvbguMp-=m4fvyD3mA-vB0y=5zOURTBMDHtRkKmob4=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday, April 28, 2025, Steve Chavez <steve(at)supabase(dot)io> wrote:
>
> 1. Do `grant evtrig_owner to member with inherit false`, then `member`
> will not be able to drop the event trigger.
>
I think they can still use set role…
After getting my head around this, and re-reading what Tom said, I think
you have the grant backwards. You’ve made member a member of owner, while
the specification would have to be making owner a member of member.
“The notion I proposed earlier that an event trigger only fires
on queries executed by roles the trigger's owner belongs to
is (AFAICS) safe to allow to anyone. If that's not good enough
for your notion of what a DB owner should be able to do, the
answer is to grant the DB owner membership in every role that
uses her database. That's effectively what the feature you're
suggesting would do anyway.” - Tom Lane
This might be better to do if you restrict yourself to use a role with the
createrole attribute instead of a superuser - since that is effectively
what you are trying to model anyway.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2025-05-07 01:38:28 | Re: 2025-05-08 release announcement draft |
Previous Message | Jonathan S. Katz | 2025-05-07 01:34:45 | Re: 2025-05-08 release announcement draft |