Re: pg_partition_tree crashes for a non-defined relation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_partition_tree crashes for a non-defined relation
Date
Msg-id 31090.1551458300@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_partition_tree crashes for a non-defined relation  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_partition_tree crashes for a non-defined relation
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
>> 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)    

Right, while you'd get zero rows out for a non-partitioned table.
WFM.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Prevent extension creation in temporary schemas
Next
From: Tom Lane
Date:
Subject: Re: NOT IN subquery optimization