Re: Allow database owners to CREATE EVENT TRIGGER - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Allow database owners to CREATE EVENT TRIGGER
Date
Msg-id CAKFQuwYBzLVFgweF20LEfO=cfNXrxsxwLU9XLMrAAs9TD5gjKg@mail.gmail.com
Whole thread Raw
In response to Re: Allow database owners to CREATE EVENT TRIGGER  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Allow database owners to CREATE EVENT TRIGGER
List pgsql-hackers
On Tuesday, April 22, 2025, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tuesday, April 22, 2025, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tuesday, April 22, 2025, Steve Chavez <steve@supabase.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.

Ok.  I missed this.

Sorry for the self-reply but this nagged at me.

It’s probably not a big deal either way, but the prior test existed to ensure that a superuser couldn’t do something they are otherwise are always permitted to do - assign object to whomever they wish.  So event_trigger.sql had a test that errored showing this anomaly.  You moved the test and now are proving it doesn’t error.  But it is not expected to error; and immediately above you already show that a non-superuser can be an owner.  We don’t need a test to show a superuser demonstrating their normal abilities.

IOW, select test cases around the feature as it is implemented now, not its history.  A personal one-off test to ensure that no super-user prohibitions remained will suffice to make sure all such code that needed to be removed is gone.

David J.

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition
Next
From: Peter Smith
Date:
Subject: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding