On 05/20/2017 05:41 AM, Tom Lane wrote:
Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
