Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
I meant about the way the documentation is phrased to introduce the
example, which is somewhat wrong because not all commands are concerned,
quite a bunch of them will not be disabled by such a command trigger.
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Sooner or later there will be one somewhere in the code path involved
> in doing a heap_delete on pg_event_trigger, or one of the subsidiary
> catalogs such as pg_depend, or maybe one that just manages to fire
> someplace during backend startup, or who knows what.
You're right that we need to be careful here, in ways that I didn't
foresee. The first thing I can think of is to disable such low level
events on system catalogs, of course.
> Hence, I want a kill switch for all event triggers that will most
> certainly work, and the just-committed patch provides one.
We absolutely need that, and running Event Triggers in standalone mode
seems counter productive to me anyway. That said maybe we need to be
able to have a per-session "leave me alone" mode of operation. What do
you think of
ALTER EVENT TRIGGER DISABLE ALL; -- just tried, no conflict
I don't think we need the ENABLE ALL variant, and it would not be
symetric anyway as you would want to be able to only enable those event
triggers that were already enabled before, and it seems to me that
"cancelling" a statement is best done with "ROLLBACK;" or "ROLLBACK TO
SAVEPOINT …;".
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
