On 05/20/2017 05:41 AM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I guess it does seem likely that most users of the hook would need to
>> do the same, but it seems confusing to pass the same function both x
>> and f(x), so my vote is to not do that.
Right, that was my thinking. (Except that my vote is to nevertheless
keep it unchanged.)
> I guess what's in the back of my mind is that the password type might
> someday not be just a function of the password, but require other
> inputs. That is, if we change the hook signature as proposed, then
> the signature of get_password_type() also becomes part of that API.
> If someday f(x) needs to become f(x,y), that becomes either more API
> breakage for users of the hook, or no change at all because it's the
> callers' problem.
>
> Maybe there's no reason to believe that that will ever happen.
I don't see that happening. It's too convenient that a password verifier
is self-identifying, i.e. that you can tell what kind of a verifier it
is, just by looking at the value, without any out-of-band information.
Although when we talked about the representation of password verifiers
in pg_authid.rolpassword, there was discussion on having a separate
"password type" field. I was against it, but some thought it would be a
good idea.
>> But I'm not disposed to spend
>> a lot of energy arguing about it, so if other people feel differently,
>> that's cool.
>
> TBH, I'm not that hot about it either. But I'm thinking this
> is an API break we don't need.
I'm going to just remove this from the open items list. But if some
other committer disagrees strongly and wants to commit this, I won't object.
- Heikki
