On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
> 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.
Okay, so the opinion moves into this direction. What would be needed
is just something like the attached patch then based on Amit's
suggestion? The routine names and comments looked fine to me so I
have not touched the surroundings, and comments are welcome.
> 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.
Yep, that's the intention since cc53123. I won't come back to return
an ERROR in any case. Here is what the patch gives for childless
partitions FWIW:
=# CREATE TABLE ptif_test (a int, b int) PARTITION BY range (a);
CREATE TABLE
=# SELECT * FROM pg_partition_tree('ptif_test');
relid | parentrelid | isleaf | level
-----------+-------------+--------+-------
ptif_test | null | f | 0
(1 row)
--
Michael