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-22 15:45:23
Message-ID: CBBFCA74-60C7-4D37-B893-8E3874AFD182@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/7/18, 10:33 AM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
> On 3/5/18, 7:08 PM, "Andres Freund" <andres(at)anarazel(dot)de> wrote:
>> On 2018-03-05 19:57:44 -0500, Tom Lane wrote:
>>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>>> One wrinkle in that plan is that it'd not be trivial to discern whether
>>>> a lock couldn't be acquired or whether the object vanished. I don't
>>>> really have good idea how to tackle that yet.
>>> Do we really care which case applies?
>>
>> I think there might be cases where we do. As expand_vacuum_rel()
>> wouldn't use missing_ok = true, it'd not be an issue for this specific
>> callsite though.
>
> I think it might be enough to simply note the ambiguity of returning
> InvalidOid when skip-locked and missing-ok are both specified. Even
> if RangeVarGetRelidExtended() did return whether skip-locked or
> missing-ok applied, such a caller would likely not be able to trust
> it anyway, as no lock would be held.

Here is a set of patches for this approach.

Nathan

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-03-22 15:50:56 Re: PL/pgSQL nested CALL with transactions
Previous Message Daniel Verite 2018-03-22 15:30:41 Re: Re: csv format for psql