| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: scram and \password |
| Date: | 2017-04-25 18:13:44 |
| Message-ID: | CA+Tgmob=P9zCS1Qrmane74m8q3EPnmY827o7OCZtotzrH-H2BQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 25, 2017 at 11:26 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> 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.
I vote for A - leave PQencryptPassword() as-is, and deprecate it.
Tell people to use the new function going forward.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-04-25 18:17:09 | Re: logical replication and PANIC during shutdown checkpoint in publisher |
| Previous Message | Petr Jelinek | 2017-04-25 18:12:05 | Re: PG 10 release notes |