Refactoring in lock.c
От | Alvaro Herrera |
---|---|
Тема | Refactoring in lock.c |
Дата | |
Msg-id | 20050513030659.GA25439@surnet.cl обсуждение исходный текст |
Ответы |
Re: Refactoring in lock.c
Re: Refactoring in lock.c Re: Refactoring in lock.c |
Список | pgsql-patches |
Patchers, Here is a small patch to refactor common functionality out of LockRelease and LockReleaseAll, creating a new static function RemoveProcLock. (This comes from Heikki's two-phase commit patch, where it is used more.) Additionally, I found that no callers of LockReleaseAll and LockRelease had any use for their return values, so I made them return void. There are two exceptions to the "no use of return value" assertion: one is the userlock contrib module, but I doubt it has much use for it in reality; I made it "return true" where it used LockRelease{,All} return value, in order not change the function's signature; users have no way to recover when user_unlock_all does not work anyway, so we are not losing anything. The other exception is LockReleaseCurrentOwner, where the only action is to raise a WARNING. Since LockRelease already raises WARNING for anything that returns a FALSE value, we don't lose anything by just returning void and dropping the warning in ResourceOwners. Please apply if there are no objections. -- Alvaro Herrera (<alvherre[a]surnet.cl>) "La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)
Вложения
В списке pgsql-patches по дате отправления: