On Wed, Apr 26, 2017 at 12:26 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Yeah, there is that. But we simply cannot change the signature of an
> existing function. It would not only produce compile-time errors when
> building old applications, which would arguably be a good thing, but it
> would also cause old binaries to segfault when dynamically linked with the
> new libpq.
Sure.
> I think it's clear that we should have a new function that takes the
> algorithm as argument. But there are open decisions on what the old
> PQencryptPassword() function should do, and also what the new function
> should do by default, if you don't specify an algorithm:
>
> A) Have PQencryptPassword() return an md5 hash.
>
> B) Have PQencryptPassword() return a SCRAM verifier
>
> C) Have PQencryptPassword() return a SCRAM verifier if connected to a v10
> server, and an md5 hash otherwise. This is tricky, because PQencryptPassword
> doesn't take a PGconn argument. It could behave like PQescapeString() does,
> and choose md5/scram depending on the server version of the last connection
> that was established.
Like the rest I vote for A, and document it as deprecated.
> ----
> char *
> PQencryptPasswordConn(PGconn *conn,
> const char *passwd,
> const char *user,
> const char *method,
> const char *options)
>
> [...]
Good for me, I was first thinking as well about having "default" as
keyword, NULL is fine as well.
Could it be possible to name the new function as PQhashPassword
instead of PQencryptPassword? From the previous threads we agreed that
encryption makes no sense in this context.
--
Michael