On Fri, Jul 21, 2017 at 9:35 AM, Yugo Nagata <nag...@sraoss.co.jp> wrote: > > On Fri, 21 Jul 2017 09:53:19 +0800 > Craig Ringer <cr...@2ndquadrant.com> wrote: > > > On 21 July 2017 at 08:42, Robert Haas <robertmh...@gmail.com> wrote: > > > > > On Thu, Jul 20, 2017 at 8:27 AM, Fabrízio de Royes Mello > > > <fabriziome...@gmail.com> wrote: > > > > I'm not sure your real needs but doesn't it material for improve Event > > > > Triggers??? > > > > > > I've thought about that, too. One problem is what to do if the user > > > hits ^C while the event trigger procedure is running. If you respond > > > to that by killing the event trigger and letting the user issue > > > commands, then the event trigger can't be used for security or > > > auditing purposes because the user might prevent it from doing > > > whatever it's intended to do with a well-timed interrupt. If you > > > ignore ^C or make it turn into FATAL, then a poorly-crafted trigger > > > can lock users out of the database. Maybe that's OK. We could say > > > "well, if you lock yourself out of the database with your logon > > > trigger, you get to shut down the database and restart in single user > > > mode to recover". > > > > > > A hook, as proposed here, is a lot simpler and lacks these concerns. > > > Installing code in C into the database is intrinsically risky > > > anywhere, and not any moreso here than elsewhere. But it's also less > > > accessible to the average user. > > > <http://www.postgresql.org/mailpref/pgsql-hackers> > > > > > > I'd favour the c hook personally. It's a lot more flexible, and can be used > > by an extension to implement trigger-like behaviour if anyone wants it, > > including the extension's choice of error handling decisions. > > > > It's also a lot simpler and less intrusive for core. Which is nice where we > > don't have something that we don't have anything compelling destined for > > core that needs it. (I want to add a bunch of hooks in the logical > > replication code in pg11 for similar reasons, and so features like DDL > > replication can be prototyped as extensions more practically). > >
I agree with you both... > > That said, isn't ExecutorStart_hook + ProcessUtility_hook able to serve the > > same job as a session-start hook, albeit at slightly higher overhead? You > > can just test to see if your initial tasks have run yet. > > Thank you for your suggestion. Certainly, we can do the similar job of a > session-start hook using these existing hooks, although these hooks are > triggered when the first query is executed not when the session is started. > Now I come to think that an additional hook is not need. > As Nagata said hooks proposed by Craing will happens only when the first query is called so I don't know how it works for session start... are we missing something? If we're going to add this hook what about add a session end hook also? Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog: http://fabriziomello.github.io >> Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello >> Github: http://github.com/fabriziomello