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-09 17:49:18 |
Message-ID: | 20181209174917.GE3415@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Michael Paquier (michael(at)paquier(dot)xyz) wrote:
> 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?
Looks alright on a quick glance, but shouldn't you also update the
comment..?
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-09 17:50:21 | Collatability of type "name" |
Previous Message | Stephen Frost | 2018-12-09 17:48:15 | Re: pg_partition_tree crashes for a non-defined relation |