On 2018/01/22 11:44, Michael Paquier wrote:
> On Sun, Jan 21, 2018 at 07:16:38PM +1300, David Rowley wrote:
>> On 20 January 2018 at 23:14, Michael Paquier <michael.paquier@gmail.com> wrote:
>>> If pg_partition_tree_tables() uses the top of the partition as input,
>>> all the tree should show up. If you use a leaf, anything under the leaf
>>> should show up. If a leaf is defined and it has no underlying leaves,
>>> then only this outmost leaf should be listed.
>>
>> hmm, that's thoroughly confusing. Just in case anyone else is stuck on
>> that, I just need to mention that a leaf is the does not have
>> branches, in nature or computer science.
>
> OK, sorry if my words are confusing. Imagine that you have the following
> partition set:
>
> p
> / \
> / \
> p1 p2
> / \
> / \
> p21 p22
>
> If pg_partition_tree_tables() uses 'p' as input argument, then I would
> imagine that it should return p, p1, p2, p21 and p22. If 'p2' is used,
> then p2, p21 and p22 are the results. If either one of p1, p21 or p22 is
> used as input, then the result is respectively p1, p21 or p22.
>
> Amit's patch seems to be doing that kind of logic by using
> find_all_inheritors, which is good. We need to make the difference
> between relations that are part of a partition set and the other ones
> which are part of an INHERIT link, and, at least it seems to me, the
> patch is not careful with that. I haven't tested what is proposed
> though, but this portion likely needs more thoughts.
Yeah, I think I completely missed that part.
I wonder what pg_partition_tree_tables() should return when passed a table
that doesn't have partitions under it? Return a 1-member set containing
itself? I also mean for tables that may inheritance children established
through plain old inheritance.
Thanks,
Amit