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-07 16:33:07 |
Message-ID: | 1D9D868E-ABA2-47EC-A757-6FC8C3AFD4E8@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2018-03-07 16:33:14 | Re: public schema default ACL |
Previous Message | Petr Jelinek | 2018-03-07 16:22:10 | Re: public schema default ACL |