Re: drop table and pg_proc - Mailing list pgsql-hackers

From mlw
Subject Re: drop table and pg_proc
Date
Msg-id 3A5DADFA.9D52893F@mohawksoft.com
Whole thread Raw
In response to drop table and pg_proc  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
Tatsuo Ishii wrote:
> 
> 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.
> 
> 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)

I have the same problem with views. If I create a view, drop/recreate
the tables to which it references, pg_dump fails unless I also drop and
recreate the view. I have seen similar behavior with indexes based on
user functions, when a function is dropped and recreated.

I suspect that this is because all these things get an OID, and the OIDs
change when things get modified. There should be a way to reassign
dependencies, perhaps vacuum should be able to do this?



-- 
http://www.mohawksoft.com


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: drop table and pg_proc
Next
From: Pete Forman
Date:
Subject: Re: AW: AW: Re: tinterval - operator problems on AIX