Alvaro Herrera <alvherre@commandprompt.com> 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
