Re: Allow database owners to CREATE EVENT TRIGGER

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: Re: Allow database owners to CREATE EVENT TRIGGER
Date: 2025-04-23 00:41:05
Message-ID: CAKFQuwZN4Emb5-WkyHYn4fCc5fw9QxcAYy9AYfUM=uJdRMZ+6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, April 22, 2025, Steve Chavez <steve(at)supabase(dot)io> wrote:

> > alter event trigger command which doesn’t need to be exercised here
>
> That part does need to be tested, I modified `AlterEventTriggerOwner_internal`
> to allow altering owners to regular users. Before it was only restricted to
> superusers.
>
> > Actually, leave the other member around, but not granted ownership, and
> both create tables, to demonstrate that a non-superuser and non-owner is
> unaffected by the trigger.
>
> I've updated the tests accordingly. Please let me know if that's what you
> had in mind.
>

Pretty much. You have a bad drop table cleanup command, and I’d drop the
entire alter event trigger owner test.

The other thing I’m wondering, but haven’t gotten around to testing, is
whether a role affected by the event trigger is able to just drop the
trigger given this implementation. I always get member/member-of dynamics
confused. Having member (possibly via set role…) trying to drop the
trigger would be good to prove that it isn’t allowed.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2025-04-23 01:03:32 Re: Allow database owners to CREATE EVENT TRIGGER
Previous Message David G. Johnston 2025-04-23 00:33:09 Re: DOCS - create publication (tweak for generated columns)