Re: Change RangeVarGetRelidExtended() to take flags argument? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Change RangeVarGetRelidExtended() to take flags argument?
Date
Msg-id CBBFCA74-60C7-4D37-B893-8E3874AFD182@amazon.com
Whole thread Raw
In response to Re: Change RangeVarGetRelidExtended() to take flags argument?  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: Change RangeVarGetRelidExtended() to take flags argument?
List pgsql-hackers
On 3/7/18, 10:33 AM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> On 3/5/18, 7:08 PM, "Andres Freund" <andres@anarazel.de> wrote:
>> On 2018-03-05 19:57:44 -0500, Tom Lane wrote:
>>> Andres Freund <andres@anarazel.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

pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: Re: csv format for psql
Next
From: Tomas Vondra
Date:
Subject: Re: PL/pgSQL nested CALL with transactions