Re: On login trigger: take three

Hi

st 9. 12. 2020 v 13:17 odesílatel Greg Nancarrow <gregn4422(at)gmail(dot)com>
napsal:

> On Tue, Dec 8, 2020 at 3:26 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
>

I see two possible questions?

1. when you introduce this event, then the new hook is useless ?

2. what is a performance impact for users that want not to use this
feature. What is a overhead of EventTriggerOnConnect and is possible to
skip this step if database has not any event trigger

Pavel

> Regards,
> Greg Nancarrow
> Fujitsu Australia
>