Hi Tom, thanks for your feedback on this.
On 11 Jul 2001 11:21:35 -0400, Tom Lane wrote:
> pgsql-bugs@postgresql.org writes:
> > ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,9) not
found
>
> Hmm, are you trying to create triggers on pg_shadow? It's hard to see
> how that message could come from an "UPDATE pg_shadow" otherwise.
I'm not trying to explicitly create triggers on pg_shadow. None of the
triggers/tables/sequences/functions I've created so far try to reference
the pg_shadow in any way, so I don't *believe* (but I could be wrong)
that I've even implicitly created a trigger on pg_shadow;
> Triggers on system catalogs don't work very well, because they won't
> be invoked as a side effect of system-initiated operations. In this
> situation, it appears that the trigger code sees that the pg_shadow
row
> was inserted in the current transaction, so it tries to look up the
row
> in the list of pending trigger events --- and doesn't find an entry,
> because CREATE USER didn't invoke the trigger code.
Before I came across this error, the approach I was following was:
-Call the WATSUSer_iou() plpgsql function that contained "CREATE USER"
statements to create the new user
-Call a plpgsql function after that, that contained "UPDATE pg_shadow"
statements to update the "valuntil" field from the pg_shadow table.
This approach was working fine. I get the feeling that this approach had
the effect of each function call being considered a separate
transaction, thus there were no errors when the "UPDATE pg_shadow"
statement was called (the "CREATE USER" transaction was commited by that
time)
> In a perfect world we'd support user-defined triggers on the system
> catalogs, but given the potential circularity problems, I doubt it's
> going to happen real soon. I'd suggest finding another approach.
Sounds reasonable. I can stick to the old approach. In case you guys
ever need to debug/ look into this I have a schema and a sequence of
commands executed that I'll keep around.
Thanks for your help.
-Kristis