Re: drop table and pg_proc

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> Suppose a function using table t1 as its argument:
> create table t1(...
> create fuction f1(t1) returns...
> And if I drop t1 then do pg_dump, I would got something like:
> failed sanity check, type with oid 1905168 was not found
> This is because the type t1 does not exist anynmore. Since not being
> able to make a back up of database is a critical problem, I think we
> have to fix this.

This is just one instance of the generic problem that we don't enforce
referential integrity across system catalogs. Since this issue has
always been there, I'm not inclined to panic about it (ie, I don't want
to try to solve it for 7.1). But we should think about a long-term fix.

> 1) remove that proc entry from pg_proc if t1 is deleted
> 2) fix pg_dump so that it ignores sunch a bogus entry
> 3) do both 1) and 2)

Ultimately we should probably do both. #2 looks easier and is probably
the thing to work on first. In general, pg_dump is fairly brittle when
it comes to missing cross-references, eg, I think it fails to even
notice a table that has no corresponding owner in pg_shadow (it should
be doing an outer not inner join for that). It'd be worth fixing
pg_dump so that it issues warnings about such cases but tries to plow
ahead anyway.

regards, tom lane