From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Michael Paquier <michael@paquier.xyz>,
        Postgres hackers <pgsql-hackers@postgresql.org>,
        Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Subject: Re: pg_partition_tree crashes for a non-defined relation
In-reply-to: <20181209185452.GF3415@tamriel.snowman.net>
References: <20181207010406.GO2407@paquier.xyz>
 <20181207230540.GA12740@paquier.xyz> <6105.1544243612@sss.pgh.pa.us>
 <20181208065436.GC1989@paquier.xyz>
 <20181208134608.GY3415@tamriel.snowman.net>
 <20181208231507.GA1833@paquier.xyz>
 <20181209174815.GD3415@tamriel.snowman.net> <16590.1544378743@sss.pgh.pa.us>
 <20181209185452.GF3415@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Sun, 09 Dec 2018 13:54:52 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19519.1544382449.1@sss.pgh.pa.us>
Date: Sun, 09 Dec 2018 14:07:29 -0500
Message-ID: <19520.1544382449@sss.pgh.pa.us>
Precedence: bulk

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> ... especially in code that's highly unlikely to break once written.

> I don't entirely buy off on the argument that it's code that's 'highly
> unlikely to break once written' though- we do add new relkinds from time
> to time, for example.  Perhaps we could have these functions run just
> once per relkind.

Well, the relevant code is likely to be "if relkind is not x, y, or z,
then PG_RETURN_NULL".  If we add a new relkind and forget to consider the
function, the outcome is a NULL result that perhaps should not have been
NULL ... but a test like this won't help us notice that.

			regards, tom lane