Re: [HACKERS] scram and \password - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] scram and \password
Date
Msg-id CAB7nPqSWP9J9PzeC7=-WjuuaL57_d+EawmzJNVsM+m7Y4gRRBA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [HACKERS] scram and \password  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] scram and \password  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas <hlinnaka@iki.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking forwalsenders
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables