Re: Change RangeVarGetRelidExtended() to take flags argument?

Thanks for taking a look.

On 3/29/18, 9:38 PM, "Michael Paquier" <michael(at)paquier(dot)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