Peter Eisentraut wrote:
> Tom Lane writes:
>
> > 1. Since the trigger is executed as soon as a tuple is inserted/
> > updated/deleted, it will write pg_pwd before the transaction is
> > committed. If you then abort the transaction, pg_pwd contains wrong
> > data.
>
> Wow, that implies that every trigger that contains non-database
> side-effects is potentially bogus. That never occured to me. Perhaps (as a
> future plan), it would be a good idea to have deferred triggers as well?
> Now that I think of it, wasn't that the very reason Jan had to invent the
> separate constraint triggers?
The reason for the trigger queue was deferrability at all. And the way it's implemented doesn't help out.
Imagine that the trigger not only affects external data, but does further checks and/or modifications to table
data.If some statement affects multiple rows, a trigger ran from the queue can still abort the transaction, but
earliertriggers have already done their external work.
I think some "AT COMMIT EXECUTE function(args)" would be better. These functions go into a separate queue
andshall not modify any database content any more. At least, it would restrict cases of external data
inconsistencyto cases, where external modifications fail.
> > itself do nothing except set a flag variable. The flag is examined
> > somewhere in xact.c after successful completion of a transaction,
> > and if it's set then we run a new transaction cycle in which we
> > read pg_shadow and write pg_pwd.
>
> If you think that this is okay (and not just a hack), then go for it.
I consider it a hack, since this particular trigger needs a global flag known explicitly by xact routines. I
likegeneral solutions instead.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #