Re: pg_partition_tree crashes for a non-defined relation

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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: 2018-12-08 13:46:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> On Fri, Dec 07, 2018 at 11:33:32PM -0500, Tom Lane wrote:
> > How about cases where the relation OID exists but it's the wrong
> > kind of relation?
> Such cases already return an error:
> =# create sequence popo;
> =# select pg_partition_tree('popo');
> ERROR: 42809: "popo" is not a table, a foreign table, or an index
> LOCATION: pg_partition_tree, partitionfuncs.c:54
> I think that's a sensible choice, because it makes no sense to look for
> the inheritors of unsupported relkinds. Perhaps you have a different
> view on the matter?

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.

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



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2018-12-08 13:56:34 Re: WIP: Avoid creation of the free space map for small tables
Previous Message Tomas Vondra 2018-12-08 13:36:38 Re: COPY FROM WHEN condition