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 1gVcvt-0001uF-HM for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Dec 2018 13:46:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gVcvs-0005nk-6q for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Dec 2018 13:46:12 +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 1gVcvr-0005nF-Vx for pgsql-hackers@lists.postgresql.org; Sat, 08 Dec 2018 13:46:12 +0000 Received: from tamriel.snowman.net ([96.255.250.162]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gVcvq-0006t3-1d for pgsql-hackers@postgresql.org; Sat, 08 Dec 2018 13:46:11 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id C04785F7A5; Sat, 8 Dec 2018 08:46:08 -0500 (EST) Date: Sat, 8 Dec 2018 08:46:08 -0500 From: Stephen Frost To: Michael Paquier Cc: Tom Lane , Postgres hackers , Amit Langote Subject: Re: pg_partition_tree crashes for a non-defined relation Message-ID: <20181208134608.GY3415@tamriel.snowman.net> References: <20181207010406.GO2407@paquier.xyz> <20181207230540.GA12740@paquier.xyz> <6105.1544243612@sss.pgh.pa.us> <20181208065436.GC1989@paquier.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IGAojOc9HqRkqa3/" Content-Disposition: inline In-Reply-To: <20181208065436.GC1989@paquier.xyz> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --IGAojOc9HqRkqa3/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, * Michael Paquier (michael@paquier.xyz) wrote: > On Fri, Dec 07, 2018 at 11:33:32PM -0500, Tom Lane wrote: > > How about cases where the relation OID exists but it's the wrong > > kind of relation? >=20 > Such cases already return an error: > =3D# create sequence popo; > CREATE SEQUENCE > =3D# select pg_partition_tree('popo'); > ERROR: 42809: "popo" is not a table, a foreign table, or an index > LOCATION: pg_partition_tree, partitionfuncs.c:54 >=20 > I think that's a sensible choice, because it makes no sense to look for > the inheritors of unsupported relkinds. Perhaps you have a different > view on the matter? We should really have a more clearly defined policy around this, but my recollection is that we often prefer to return NULL rather than throwing an error for the convenience of people doing things like querying pg_class using similar functions. I wonder if we maybe should have a regression test for every such function which just queries the catalog in a way to force the function to be called for every relation defined in the regression tests, to ensure that it doesn't segfault or throw an error.. Thanks! Stephen --IGAojOc9HqRkqa3/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJcC8sgAAoJEO1sijiDR2RVMQ4QAI8Gt+iihym2GULWhzv7MsG3 hkUAZAA+yEAB0vzn3enVqoIslLlV3cjzcvXkpobAn8hEFLhMqt39GnyFCrwUl69n 6eg3QyRksBKfrcGPlMtLBYLvW4CDY2m5qVyDEA5OvGBQJ0jWyr8hhd7mnVGpEbPb pBcjZOGBryy5WEN3Kbv8ZxmdfsZhNm53VoCGX/ReO7R7xgDDNOLeK5sMz8gBWPQU S8QSEQsT9+wVrmx1omzsA1P34lTIvn01FIRsPTR3MhqmuslCk4BpEOTg2ORlP2x9 Plb9PAqGo7gd4cqtPRKREC59SwmISexoMn58OsxDYmXZaXhsy9SLFAo/SSOW05J/ 7DuTnBkb+C8bnwYTvnXFPW3Q1QItLBewMYay8/xBXZZwjemWIwJjeBpIEvBoq8AE y6pO3H7bQNINbtRCMaQRacczptRyqTnED7t7I0MNXUhr18OCIkpq4LaclUkidWYf 2QVWZTr9wmOjCbFxqhtSwGbpTRyEQM/xTsD8yIn/trvVMCP7IK8SYz0GkRf7tlaV zvS0B5uhNfgLkdFyI0/lVakIpWlDrzmCGFK6/e5fDaG+Ya1E1wYN3Y9HSt226xYK ItU5rIa8Iynn/94ZwDAWZ8R/+Er6DY0+bHlB6RvAGhOSnCdq+o+RSXx6+aBP/k3P wiB289cDw0SaT6NKIvJJ =TuTg -----END PGP SIGNATURE----- --IGAojOc9HqRkqa3/--