Amit Langote wrote:
> 2. Something strange about how dependencies are managed:
>
> create table p (a char) partition by list (a);
> create table pa partition of p for values in ('a');;
> create table pb partition of p for values in ('b');
> create index on p (a);
> drop table pa;
> ERROR: cannot drop table pa because other objects depend on it
> DETAIL: index p_a_idx depends on table pa
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
Hmm, this is quite nasty and I'm not seeing any reasonable way to fix
it. The problem is that we have an internal dep from the parent index
to the partition index, which prompts us to recurse the chase of
dependencies inverting the way the dependencies flow -- the "case 3" in
findDependentObjects:
/*
* 3. Not all the owning objects have been visited, so
* transform this deletion request into a delete of this
* owning object.
The problem is that we don't want the partition index to go away unless
it's together with its parent index, except if the table which contains
it goes away first. We have no way to specify this condition ... Maybe
something like sticking a phony additional record in pg_depend that
causes the partition index to get added to the targetObjects list ahead
of time ... but that doesn't work either, because we still want to chase
the internal deps in that case. Hm.
Maybe we need a new "auto internal" deptype with a mix of semantics of
the other two deptypes. It seems a bit ugly and I'm not sure it'd work
either ... I'll try to code it tomorrow.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services