Before I forget any more, this is a brain of issues/considerations/concerns with our (partial) transition to partitioned tables over the last ~9 months. I believe these are all documented behaviors, but could be seen by users as a gratuitious/unexpected change or rough edge and the differences could perhaps be mitigated. I realize there's maybe no good time or way to change most of these, but maybe the list will be helpful to somebody in avoiding unexpected transitional issues. . DROP TABLE on a parent no longer fails without CASCADE (dependencies of relkind='p' are deptype='a' "soft" dependencies) 8b4d582d279d784616c228be58af1e39aa430402 . ANALYZE relkind_p also updates stats of child (whereas ANALYZE relkind_r only updates stats for parent); it's unclear if there's any reason why it wasn't always done this way(?). I end up having to conditionize processing based on relkind. 3c3bb99330aa9b4c2f6258bfa0265d806bf365c3 . The docs say: if detaching/re-attach a partition, should first ADD CHECK to avoid a slow ATTACH operation. Perhaps DETACHing a partition could implicitly CREATE a constraint which is usable when reATTACHing? . relkind_p has no entry in pg_stat_user_tables (last_analyze, etc). Maybe the view could do the needed CASE ... (SELECT min() FROM pg_inherits JOIN psut) . ALTER TABLE ATTACH requires specifying bounds: Maybe it sounds naive to suggest one would want to avoid that; but consider: we ended up adding both shell and python logic to parse the table name to allow detaching and reattaching partitions. I think it'd be a nice if the bounds were inferred if there was a single constraint on the partition key. . ALTER TABLE ATTACH has reversed order of child vs parent relative to NO/INHERIT. . And actually, having both ALTER TABLE DE/TACH vs NO/INHERIT is itself messy: we ended up having branches (both shell and python) to handle both cases (at least for a transitional period, but probably we'll need to continue handling both into the indeterminate future). Cheers, Justin
