| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(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-21 22:20:54 |
| Message-ID: | CAB7nPqSWP9J9PzeC7=-WjuuaL57_d+EawmzJNVsM+m7Y4gRRBA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I'll continue reviewing the rest of the patch on Monday, but one glaring
> issue is that we cannot add an argument to the existing libpq
> PQencryptPassword() function, because that's part of the public API. It
> would break all applications that use PQencryptPassword().
>
> What we need to do is to add a new function. What should we call that? We
> don't have a tradition of using "Ex" or such suffix to mark extended
> versions of existing functions. PQencryptPasswordWithMethod(user, pass,
> method) ?
Do we really want to add a new function or have a hard failure? Any
application calling PQencryptPassword may trap itself silently if the
server uses scram as hba key or if the default is switched to that,
from this point of view extending the function makes sense as well.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-04-21 22:22:36 | Re: Partition-wise join for join between (declaratively) partitioned tables |
| Previous Message | Andres Freund | 2017-04-21 21:45:14 | Re: [COMMITTERS] pgsql: Replication lag tracking for walsenders |