Re: [HACKERS] update_pg_pwd trigger does not work very well
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] update_pg_pwd trigger does not work very well |
Дата | |
Msg-id | m12PKtl-0003kGC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] update_pg_pwd trigger does not work very well (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 queue. But as soon as someone does SET CONSTRAINTS ALL IMMEDIATE; it will be fired if queued or as soon as it appears. So it's not the final solution. 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) #
В списке pgsql-hackers по дате отправления: