Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> then dumped with the v7.3 pg_dumpall which generated:
> CREATE CONSTRAINT TRIGGER "<unnamed>"
> AFTER INSERT OR UPDATE ON trans
> NOT DEFERRABLE INITIALLY IMMEDIATE
> FOR EACH ROW
> EXECUTE PROCEDURE "RI_FKey_check_ins" ('<unnamed>', 'trans', 'meter', 'UNSPE
> CIFIED', 'meter_id', 'id');
Yeek. The lack of a FROM <table> clause in that trigger definition is
why it's not working. IIRC, the FROM was optional in pre-7.3 releases,
but it is *required* now. (We probably should adjust the syntax
accordingly.)
7.3 pg_dump is not working hard enough to regenerate the appropriate
info, which we can fix, but I'm wondering how it got that way in the
first place. The bug that could originally cause tgconstrrelid to be
forgotten was a pg_dump bug that existed up to about 7.0. Is it
possible that these tables have a continuous history of being dumped
and reloaded back to 7.0 or before?
Anyway the quickest fix seems to be to manually drop the triggers
and reconstruct the FK relationships with ALTER TABLE ADD FOREIGN KEY
commands. If that seems too messy to do by hand, you can wait till
I've got a pg_dump patch to do it for you.
regards, tom lane