From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] A hook for session start |
Date: | 2017-07-21 00:42:45 |
Message-ID: | CA+TgmoaZifFZnia7vNvv5_BBnV0i2tjqPeO3mkkQ+TPeTk4=RQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 20, 2017 at 8:27 AM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-07-21 01:53:19 | Re: [PATCH] A hook for session start |
Previous Message | Tatsuo Ishii | 2017-07-20 23:11:07 | More optimization effort? |