Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I'm working on #2. Here is a partial fix for pg_dump, FYI. If it looks
> ok, I'll do more cleanup...
Looks OK as far as it goes. The other flavor of problems that pg_dump
has in this area are in doing inner joins across system catalogs ...
> Tatsuo Ishii <[EMAIL PROTECTED]> 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
Add to TODO:
* Enforce referential integrity for system tables
> Tatsuo Ishii <[EMAIL PROTECTED]> 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:
> This is just one instance of the generic problem that we don't enforce
> referential integrity across system catalogs. Since this issue has
Wouldn't be easy to do for views (rules) anyway - table oids are somewhere
in the body of rule, they are not just keys in column. Also, triggers are
handl
Tatsuo Ishii <[EMAIL PROTECTED]> 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
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
