Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] update_pg_pwd trigger does not work very well

From: wieck(at)debis(dot)com (Jan Wieck)
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] update_pg_pwd trigger does not work very well
Date: 2000-02-28 07:47:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> [Charset ISO-8859-1 unsupported, filtering to ASCII...]
> > 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?
> Yes!  I remember him talking about this.  I bet you can just modify your
> trigger to be of that type.

    He  could make the trigger look like a by default deferred RI
    trigger in pg_trigger, of course. Then it will  go  onto  the

    But as soon as someone does


    it  will be fired if queued or as soon as it appears. So it's
    not the final solution.



# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-02-28 07:50:01
Subject: Re: [SQL] prob with aggregate and group by - returns multiples
Previous:From: Jan WieckDate: 2000-02-28 07:42:08
Subject: Re: [HACKERS] type coerce problem with lztext

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group