Re: pg_partition_tree crashes for a non-defined relation
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Postgres hackers <pgsql-hackers@postgresql.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2018-12-08T23:15:07Z
Lists: pgsql-hackers
On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote: > 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. Yes, that's visibly right. At least that's what I can see from the various pg_get_*def and pg_*_is_visible. Returning NULL would indeed be more consistent. > 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.. Like sqlsmith? It looks hard to me to make something like that part of the main regression test suite, as that's going to be costly and hard to scale with. -- Michael
Commits
-
Test partition functions with legacy inheritance children, too
- d12fbe2f8e5d 12.0 landed
-
Consider only relations part of partition trees in partition functions
- 3422955735d9 12.0 landed
-
Make pg_partition_tree return no rows on unsupported and undefined objects
- 0f3cdf873e7d 12.0 landed
-
Tweak pg_partition_tree for undefined relations and unsupported relkinds
- cc53123bcc9d 12.0 landed