On Sun, 2006-10-15 at 15:15 -0400, Tom Lane wrote: > Well, of course not: it's a BEFORE trigger, so the row insertion hasn't > actually happened yet. I think you need to split this operation into a > BEFORE trigger that changes the ID, and an AFTER trigger that propagates > the data into the other table. Hmm. I tried that, But I'm stuck with finding a way to propagate the 'intermediate data' between BEFORE/AFTER triggers, *outside* of a TABLE structure. That data is easily accesable inside the BEFORE TRIGGER as simple variable. But, would it work if I drop foreign key constraint on AUX table in BEFORE INSERT trigger function, and resotre it back in AFTER INSERT? ... simply rising an error (thus aborting INSERT) if the later fails? Are there scenarios, leading to foreign key consistancy loss if I do that? Ideas? -- -R
