Date: Wed, 27 Feb 2019 15:48:08 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>,
	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
Message-ID: <20190227184808.GA17357@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <19520.1544382449@sss.pgh.pa.us>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2018-Dec-09, Tom Lane wrote:

> 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.

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.

alvherre=# select * from pg_partition_tree('information_schema.sequences');
 relid | parentrelid | isleaf | level 
-------+-------------+--------+-------
       |             |        |      
(1 fila)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services