On 2018/01/27 3:32, Robert Haas wrote:
> On Fri, Jan 26, 2018 at 7:45 AM, Michael Paquier
> <michael.paquier@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
