On Wed, Sep 06, 2023 at 10:23:55PM +0200, Daniel Gustafsson wrote:
> > On 6 Sep 2023, at 16:22, Robert Haas <robertmhaas@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