Re: Change RangeVarGetRelidExtended() to take flags argument?
От | Bossart, Nathan |
---|---|
Тема | Re: Change RangeVarGetRelidExtended() to take flags argument? |
Дата | |
Msg-id | 1D9D868E-ABA2-47EC-A757-6FC8C3AFD4E8@amazon.com обсуждение исходный текст |
Ответ на | Re: Change RangeVarGetRelidExtended() to take flags argument? (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Change RangeVarGetRelidExtended() to take flags argument?
|
Список | pgsql-hackers |
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. Nathan
В списке pgsql-hackers по дате отправления: