Alvaro Herrera <[EMAIL PROTECTED]> writes: > Greg Stark wrote: > > > Well I'm not actually deleting anything. The dependency is between the two > > tables and I don't want to delete either of the tables. > > > > Perhaps what should really be happening here is that there should be > > dependencies from the pg_inherit entry to the two tables rather than from > > one > > table to the other. > > > > Then a simple performDeletion on the pg_inherit entry would take care of the > > dependencies. > > Sounds like a reasonable thing to do ... If you drop the parent table, > does that cascade to the child table as well? Maybe what should happen > is that the child table is "disinherited".
I think what should happen is: . If you drop a child the pg_inherit line (and dependencies) silently disappears but the parent stays. . If you drop a parent you get an error unless you use cascade in which case the pg_inherits line and the child all go away. . If you disown the child the pg_inherit line (and dependencies) is deleted At least that's what partitioned table users would want. In that case the partitions are creatures of the main table with no identity of their own. But perhaps that's not the case for other users of inherited tables? I'm a bit confused about what pg_depends entries would be necessary then. If there's something like this there: Child Table <--(AUTO)-- pg_inherit entry --(NORMAL)-> Parent Table Then deleting the child table will correctly delete the pg_inherits line, but deleting the parent with CASCADE will stop at the pg_inherits line without deleting the child. Whereas something like this: Child Table <---(AUTO)--- pg_inherit entry --(NORMAL)-> Parent Table --(NORMAL)--> Would make the cascade go through but mean that I can't drop the pg_inherit line with performDeletion() without having the child table disappear. -- greg ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq