On 2018/01/27 3:32, Robert Haas wrote: > On Fri, Jan 26, 2018 at 7:45 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> There could be value in having a version dedicated to inheritance trees >> as well, true enough. As well as value in having something that shows >> both. Still let's not forget that partition sets are structured so as >> the parents have no data, so I see more value in having only partitions >> listed, without the INHERIT part. Opinions from others are of course >> welcome. > > Well, partitioning and inheritance can't be mixed. A given table has > either partitions OR inheritance children OR neither.
That's true. > If it has > either partitions or inheritance children, find_all_inheritors will > return them. Otherwise, I think it'll just return the input OID > itself. So I don't quite see, if we're going to add a convenience > function here, why wouldn't just define it to return the same results > as find_all_inheritors does? So if all we're doing is trying to make find_all_inheritors() accessible to users through SQL, it makes sense to call it pg_get_inheritance_tables() rather than pg_partition_tree_tables(). Thanks, Amit
