Re: pg_partition_tree crashes for a non-defined relation

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Stephen Frost <sfrost(at)snowman(dot)net>
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 23:59:26
Message-ID: 20181208235926.GB1833@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 09, 2018 at 08:15:07AM +0900, Michael Paquier wrote:
> 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.

Thinking more about your argument, scanning fully pg_class is quite
sensible as well because there is no need to apply an extra qual on
relkind, so let's change the function as you suggest, by returning NULL
on invalid relation type. Any opinions about the attached then which
does the switch?
--
Michael

Attachment Content-Type Size
partition-tree-invalid-v2.patch text/x-diff 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2018-12-09 00:16:01 Too-short timeouts in test code
Previous Message Michael Paquier 2018-12-08 23:15:07 Re: pg_partition_tree crashes for a non-defined relation