Re: try_relation_open and relation_open behave different. - Mailing list pgsql-hackers

From Xing GUO
Subject Re: try_relation_open and relation_open behave different.
Date
Msg-id CACpMh+D5iSQ+-mHJrXCJDZ+KZ3zBTeTZsgP4eRnZJA7Kk=LEGw@mail.gmail.com
Whole thread Raw
In response to Re: try_relation_open and relation_open behave different.  (Michael Paquier <michael@paquier.xyz>)
Responses Re: try_relation_open and relation_open behave different.  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Mon, Oct 18, 2021 at 2:45 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Oct 18, 2021 at 01:56:07PM +0800, Xing GUO wrote:
> My question is, is it a deliberate design that makes try_relation_open and
> relation_open different? Shall we mention it in the comment of
> try_relation_open OR adding the checker to relation_open?

I am not sure what you mean here, both functions are include comments
to explain their differences, so..

The comments in try_relation_open says:

```
/* ----------------
 * try_relation_open - open any relation by relation OID
 *
 * Same as relation_open, except return NULL instead of failing
 * if the relation does not exist.
 * ----------------
 */

```

However, I can open an "uncommitted" relation using relation_open() and cannot open it using try_relation_open().
Since Postgres doesn't write the "uncommitted" relation descriptor to SysCache and try_relation_open() checks if the
relation exists in SysCache while relation_open() doesn't check it.
 
--
Michael

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Partition Check not updated when insert into a partition
Next
From: Michael Paquier
Date:
Subject: Re: BUG #17220: ALTER INDEX ALTER COLUMN SET (..) with an optionless opclass makes index and table unusable