Horton

Re: Change RangeVarGetRelidExtended() to take flags argument?

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-03-30T17:08:26Z
Lists: pgsql-hackers

Attachments

Thanks for taking a look.

On 3/29/18, 9:38 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
> On Thu, Mar 29, 2018 at 05:15:14PM -0700, Andres Freund wrote:
>> On 2018-03-22 15:45:23 +0000, Bossart, Nathan wrote:
>>> +	/* verify that conflicting options are not specified */
>>> +	Assert((flags & (RELID_NOWAIT | RELID_SKIP_LOCKED)) != (RELID_NOWAIT | RELID_SKIP_LOCKED));
>>> +
>
> This is more readable as follows I think:
> Assert((flags & RELID_NOWAIT) == 0 || (flags & RELID_SKIP_LOCKED) == 0);

Agreed.  I've changed this in v2 of 0002.

> I would suggest to use uint8, uint16 or uint32 for the flags of
> RangeVarGetRelidExtended instead of int.  That's the practice in other
> similar APIs with control flags.

I've made this change as well.

> + * Note that if RELID_MISSING_OK and RELID_SKIP_LOCKED are both specified, a return
> + * value of InvalidOid could either mean the relation is missing or it could not be
> + * locked.
> Perhaps we could generate a DEBUG message to help with making the
> difference for developers?

I adjusted the existing log statements to generate a DEBUG message for
missing-ok and skip-locked.

I'll go ahead and post rebased patches for VACUUM (SKIP LOCKED) in the
other thread [0].

Nathan

[0] https://postgr.es/m/20171201160907.27110.74730%40wrigleys.postgresql.org

Commits

  1. Add SKIP_LOCKED option to RangeVarGetRelidExtended().

  2. Combine options for RangeVarGetRelidExtended() into a flags argument.