Re: pg_partition_tree crashes for a non-defined relation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_partition_tree crashes for a non-defined relation
Date: 2019-03-01 16:38:20
Message-ID: 31090.1551458300@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-03-01 16:44:17 Re: NOT IN subquery optimization
Previous Message Tom Lane 2019-03-01 16:35:55 Re: Prevent extension creation in temporary schemas