On Thu, 2007-01-11 at 15:10 +0100, Alban Hertroys wrote: > Rafal Pietrak wrote: > > Hi! > > > > I'm re-posting this message again in hope someone would have a look at > > the case again. .. it's pending. > > You were given a solution; defer the foreign key constraint. Well. I were, but probably I'm doing something wrong with 'deferring the trigger'. When I put: "SET CONSTRAINTS ALL DEFERRED ; " *before* the UPDATE statement *within* the trigger function (just after BEGIN statement there). After doing so, notheing changes. I get the same ERROR. (all screenlogs were included in previous posts, so I'll spare those here). So may be "SET CONSTRAINTS .... DEFERRED " should be used somehow differently? I've never had any use for that construct, may be I miss something? > Alternatively, you may want to re-think your trigger function so that it > does things in the right order. I cannot see *any* way to reorder the events in the triger function. The function is short anough 'not to allow' :) for reordering - it just makes an UPDATE to some other table (where it puts a reference to the 'fresh ROW') and stores the result of that update in the newly created ROW. And the problem is, that UPDATE puts a reference to the fresh ROW and that the UPDATE statement does NOT SEE the 'freshly created ROW' - may be this is not a case of 'too early constraint check', but rather a problem of 'visibility' of data (new data) within a single transaction (an UPDATE is launched within the trigger transaction - should see already created ROW, shouldn't it?). N.B. All the code that does fail is in my previous posts. But as this is the 'second round' of my 'call for help' - I get an impression, that there may actually not be a solution. Too bad. -R
