Re: pg_partition_tree crashes for a non-defined relation

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2019/03/01 9:22, Michael Paquier wrote:
>> What I am writing next sounds perhaps a bit fancy, but in my opinion a
>> normal table is itself a partition tree, made of one single member:
>> itself.

> That's what we discussed, but it seems that we ended up allowing regular
> standalone tables (possibly in inheritance trees) only because it
> *appeared* to work. Alvaro already pointed out what appears to be a bug
> in how we compute the value of level. Instead of trying to fix it, I
> agree we should just disallow tables that are not a partitioned
> table/index or a partition (relispartition).

FWIW, I don't agree with Michael's suggestion above. A plain table is
significantly different from a partitioned table with no children:
you can store rows in the former but not the latter, and you can add
partitions to the latter but not the former. So conflating the two
doesn't seem likely to lead to any good outcome.

But, having said that, we've learned that it's generally bad for
catalog-query functions to fail outright just because they're pointed
at the wrong kind of catalog object. So I think that what we want here
is for pg_partition_tree to return NULL or an empty set or some such
for a plain table, while its output for a childless partitioned table
should be visibly different from that. I'm not wedded to details
beyond that idea.

regards, tom lane