Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gza8H-0008Dq-DO for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Mar 2019 04:50:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gza8E-0000kH-Iq for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Mar 2019 04:50:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gza8E-0000jL-Az for pgsql-hackers@lists.postgresql.org; Fri, 01 Mar 2019 04:50:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gza7u-0000oh-Rj for pgsql-hackers@postgresql.org; Fri, 01 Mar 2019 04:50:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x214oGdl010306; Thu, 28 Feb 2019 23:50:16 -0500 From: Tom Lane To: Amit Langote cc: Michael Paquier , Alvaro Herrera , Stephen Frost , Postgres hackers Subject: Re: pg_partition_tree crashes for a non-defined relation In-reply-to: References: <20190228014549.GD1617@paquier.xyz> <20190228193203.GA26151@alvherre.pgsql> <20190301002204.GA1348@paquier.xyz> Comments: In-reply-to Amit Langote message dated "Fri, 01 Mar 2019 13:38:28 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10304.1551415816.1@sss.pgh.pa.us> Date: Thu, 28 Feb 2019 23:50:16 -0500 Message-ID: <10305.1551415816@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote 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