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