Re: Change RangeVarGetRelidExtended() to take flags argument?

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Change RangeVarGetRelidExtended() to take flags argument?
Date: 2018-03-30 17:08:26
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

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 */
>>> +
> 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].



Attachment Content-Type Size
v2-0001-Combine-options-for-RangeVarGetRelidExtended-into.patch application/octet-stream 11.9 KB
v2-0002-Add-skip-locked-option-to-RangeVarGetRelidExtende.patch application/octet-stream 3.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2018-03-30 17:11:16 Re: Feature Request - DDL deployment with logical replication
Previous Message Konstantin Knizhnik 2018-03-30 17:04:25 Re: JIT compiling with LLVM v12.2