From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Mikhail Gribkov <youzhick(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: GUC for temporarily disabling event triggers |
Date: | 2023-04-05 08:10:32 |
Message-ID: | ZC0s+BRMqRupDInQ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 03, 2023 at 11:35:14PM +0200, Daniel Gustafsson wrote:
> Yeah. The patch as it stands allow for disabling specific types rather than
> all-or-nothing, which is why the name was "ignore".
FWIW, I agree with Robert's points here:
- disable_event_triggers or ignore_event_triggers = off leads to a
double-negative meaning, which is a positive. Depending on one's
native language that can be confusing.
- Being able to write a list of event triggers working would be much
more interesting than just individual elements.
- There may be an argument for negated patterns? Say,
a "!sql_drop,!ddl_command_start" would cause sql_drop and
ddl_command_start to be disabled with all the others enabled, and one
should not ne able to mix negated and non-negated patterns.
A few days before the end of the commit fest, perhaps you'd better
head towards having only an event_trigger = on | off or all | none and
consider expanding that later on? From what I get at the top of the
thread, this would satisfy the main use case you seemed to worry
about to begin with.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2023-04-05 08:21:02 | Re: Add index scan progress to pg_stat_progress_vacuum |
Previous Message | Drouvot, Bertrand | 2023-04-05 08:01:56 | Re: Minimal logical decoding on standbys |