Re: Use of systable_beginscan_ordered in event trigger patch

On Fri, Dec 14, 2012 at 3:46 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)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 …;".

ISTM that a PGC_SUSER GUC, as I proposed previously, would serve this
need adequately, without the cost of more cruft in gram.y.

Am I wrong?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company