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.paqu...@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