Horton

Re: pg_partition_tree crashes for a non-defined relation

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Postgres hackers <pgsql-hackers@postgresql.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2019-02-28T01:45:49Z
Lists: pgsql-hackers

Attachments

On Wed, Feb 27, 2019 at 03:48:08PM -0300, Alvaro Herrera wrote:
> I just happened to come across the result of this rationale in
> pg_partition_tree() (an SRF) while developing a new related function,
> pg_partition_ancestors(), and find the resulting behavior rather absurd
> -- it returns one row with all NULL columns, rather than no rows.  I
> think the sensible behavior would be to do SRF_RETURN_DONE() before
> stashing any rows to the output, so that we get an empty result set
> instead.

Hmm.  Going through the thread again NULL was decided to make the
whole experience consistent, now by returning nothing we would get
a behavior as consistent as when NULL is used in input, so point taken
to tune the behavior for unsupported relkinds and undefined objects.

Does the attached look fine to you?
--
Michael

Commits

  1. Test partition functions with legacy inheritance children, too

  2. Consider only relations part of partition trees in partition functions

  3. Make pg_partition_tree return no rows on unsupported and undefined objects

  4. Tweak pg_partition_tree for undefined relations and unsupported relkinds