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 |
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 |