On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > There are two maybe generic questions? > > 1. Maybe we can introduce more generic GUC for all event triggers like > disable_event_triggers? This GUC can be checked only by the database owner or > super user. It can be an alternative ALTER TABLE DISABLE TRIGGER ALL. It can > be protection against necessity to restart to single mode to repair the event > trigger. I think so more generic solution is better than special > disable_client_connection_trigger GUC. > > 2. I have no objection against client_connection. It is probably better for > the mentioned purpose - possibility to block connection to database. Can be > interesting, and I am not sure how much work it is to introduce the second > event - session_start. This event should be started after connecting - so the > exception there doesn't block connect, and should be started also after the > new statement "DISCARD SESSION", that will be started automatically after > DISCARD ALL. This feature should not be implemented in first step, but it > can be a plan for support pooled connections >
I've created a separate patch to address question (1), rather than include it in the main patch, which I've adjusted accordingly. I'll leave question (2) until another time, as you suggest. See the attached patches. Regards, Greg Nancarrow Fujitsu Australia
v1-0001-Add-new-config-parameter-disable_event_triggers.patch
Description: Binary data
v1-0002-Add-new-client_connection-event-supporting-a-logon-trigger.patch
Description: Binary data
