From: | Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Relation 0 does not exist |
Date: | 2002-09-26 15:31:01 |
Message-ID: | 20020926163101.B13497@quartz.newn.cam.ac.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, Sep 26, 2002 at 09:59:32AM -0400, Tom Lane wrote:
> Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)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?
I wrote the system last year and it started running for real
Thu 29 Mar 22:41:25 2001
I think that is after 7.0? It has gone through a number of dump/restore
cycles.
> 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.
Just a note on output. Before I had
\d trans...
Indexes: firsttimei_idx btree (firsttimei),
srcpeername_idx btree (sourcepeername)
Triggers: RI_ConstraintTrigger_14413070,
RI_ConstraintTrigger_14413073
\d meter...
Indexes: meter_pkey primary key btree (id)
Triggers: RI_ConstraintTrigger_14413071,
RI_ConstraintTrigger_14413072
\d stats...
Indexes: stats_pkey primary key btree (id)
Triggers: RI_ConstraintTrigger_14413074,
RI_ConstraintTrigger_14413075
after drop trigger/alter table add foreign key:
\d trans
Indexes: firsttimei_idx btree (firsttimei),
srcpeername_idx btree (sourcepeername)
Foreign Key constraints: $1 FOREIGN KEY (meter_id) REFERENCES meter(id) MATCH FULL ON UPDATE NO ACTION ON DELETE NO ACTION,
$2 FOREIGN KEY (stats_id) REFERENCES stats(id) MATCH FULL ON UPDATE NO ACTION ON DELETE NO ACTION
\d meter...
Indexes: meter_pkey primary key btree (id)
\d stats...
Indexes: stats_pkey primary key btree (id)
I take it the difference is because before tgconstrrelid was zero, and now
it isn't? (Apart from pg_sync_pg_pwd and pg_sync_pg_group)
Thank you for the help! (Working now :-) .. now to see what's up with libpq++)
Patrick
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-26 15:39:09 | Re: Relation 0 does not exist |
Previous Message | Shridhar Daithankar | 2002-09-26 15:29:01 | Re: Performance while loading data and indexing |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-26 15:39:09 | Re: Relation 0 does not exist |
Previous Message | Shridhar Daithankar | 2002-09-26 15:29:01 | Re: Performance while loading data and indexing |