On Wed, Sep 06, 2023 at 10:23:55PM +0200, Daniel Gustafsson wrote: > > On 6 Sep 2023, at 16:22, Robert Haas <robertmh...@gmail.com> wrote: >> I usually prefer to give things a positive sense, talking about >> whether things are enabled rather than disabled. I'd do event_triggers >> = off | on, like we have for row_security. YMMV, though. > > Fair enough, I don't have strong opinions and I do agree that making this work > like row_security is a good thing for consistency. Done in the attached.
This point has been raised a couple of months ago: https://www.postgresql.org/message-id/ZC0s%2BBRMqRupDInQ%40paquier.xyz +SET event_triggers = 'on'; +CREATE POLICY pguc ON event_trigger_test USING (FALSE); +DROP POLICY pguc ON event_trigger_test; This provides checks for the start, end and drop events. Shouldn't table_rewrite also be covered? + GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE I am a bit surprised by these two additions. Setting this GUC at file-level can be useful, as is documenting it in the control file if it provides some control of how a statement behaves, no? + Allow temporarily disabling execution of event triggers in order to + troubleshoot and repair faulty event triggers. All event triggers will + be disabled by setting it to <literal>true</literal>. Setting the value + to <literal>false</literal> will not disable any event triggers, this + is the default value. Only superusers and users with the appropriate + <literal>SET</literal> privilege can change this setting. Event triggers are disabled if setting this GUC to false, while true, the default, allows event triggers. The values are reversed in this description. -- Michael
signature.asc
Description: PGP signature