Re: Resource Owner reassign Locks

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
>> On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> That's the safest way. Sometimes you can decide that a function can not
>>> sanely be called by external code and thus change the signature. But I'd
>>> rather not risk or here, IRS quite possible that one pod these is used by a
>>> extension.

>> Where are we on this? Could there be a version for <= 9.2?

> Once the code has to be rewritten, my argument that it has been working "in
> the field" for a while doesn't really apply anymore.

Yeah.

However, I'm not entirely following Andres' concern here. AFAICS,
the only externally visible API change in commit eeb6f37d8 was that
LockReleaseCurrentOwner and LockReassignCurrentOwner gained some
arguments. That would certainly be an issue if there were any plausible
reason for extension code to be calling either one --- but it seems to me
that those functions are only meant to be called from resowner.c. What
other use-case would there be for them?

Were any follow-on commits needed to fix problems induced by eeb6f37d8?
I couldn't find any in a quick trawl of the commit logs, but I could have
missed something.

regards, tom lane