"Donald Fraser" <demolish@cwgsy.net> writes:
> The BEFORE trigger function basically does nothing to modify the tuple in=
> any way. It does run a SELECT on the same table to do some routine checks =
> and before it can exit the function it sets a global flag to tell the AFTER=
> trigger function what to do.
> The AFTER trigger function resets the flag set by the BEFORE function and=
> then performs some administration commands for users . In this instance it=
> issues a "DROP USER" command.
And this global flag is stored how?
> Have I misunderstood trigger functions or is this a legitimate bug?
I suspect you have failed to consider that the AFTER trigger fires once
per modified row. If the "global flag" is really global, then it will
appear cleared to all but the first firing.
I am not sure what your intentions are with all this, but from here
it looks suspiciously like you are inventing a lot of unnecessary
mechanism. Why don't you just drop the user in the BEFORE trigger?
Or forget the BEFORE trigger and drop the user in the AFTER trigger?
I can't see any reason for two triggers. I also wonder whether you've
aware that DROP USER is transactional --- if the transaction rolls back
due to error, so does the DROP. So I don't see any strong need not to
just do the DROP in the BEFORE trigger.
regards, tom lane
