On Thu, Dec 13, 2012 at 6:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Dec 12, 2012 at 3:51 PM, Dimitri Fontaine
>> <dimitri@2ndquadrant.fr> wrote:
>>> Robert, does that ring a bell to you? I'm going to crawl the archives
>>> tomorrow if not…
>
>> Yeah, I'm pretty sure you can't set event triggers of any kind on
>> event triggers. You proposed to allow some stuff that would affect
>> "every command", but I yelled and screamed about that until we got rid
>> of it, 'cuz it just seemed way too dangerous.
>
> In that case the docs should probably mention it more prominently;
> the example in CREATE EVENT TRIGGER is misleadingly described, for sure.
>
> I suspect there are still ways to shoot yourself in the foot with a
> broken event trigger, but it's not quite as trivial as I thought.
I'm smart enough not to doubt you, but I'd sure appreciate a hint as
to what you're worried about before we start building more on top of
it. I don't want to sink a lot of work into follow-on commits and
then discover during beta we have to rip it all out or disable it. It
seems to me that if you can always drop an event trigger without
interference from the event trigger system, you should at least be
able to shut it off if you don't like what it's doing. I'm a little
worried that there could be ways to crash the server or corrupt data,
but I don't know what they are. ISTM that, at least for the firing
point we have right now, it's not much different than executing the
event trigger code before you execute the DDL command, and therefore
it should be safe. But I'm very aware that I might be wrong, hence
the extremely conservative first commit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
