Re: pg_partition_tree crashes for a non-defined relation

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: pg_partition_tree crashes for a non-defined relation
Date: 2019-02-27 18:48:08
Message-ID: 20190227184808.GA17357@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018-Dec-09, Tom Lane wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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

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

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Derek Hans 2019-02-27 18:53:48 Re: Update does not move row across foreign partitions in v11
Previous Message Alvaro Herrera 2019-02-27 18:37:23 Re: psql display of foreign keys