On 05/20/2017 05:41 AM, Tom Lane wrote:
Robert Haas 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.
Robert Haas 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.
I guess what's in the back of my mind is that the password type
On Fri, May 19, 2017 at 5:31 PM, Tom Lane wrote:
>> Anyone else want to vote? So far I count 3-1 in favor of making this change.
>
> Actually, on looking at the final form of the patch, it's hard to think
> that it's not just useless API churn. The one existing hook user
Robert Haas writes:
> On Thu, May 18, 2017 at 2:37 AM, Heikki Linnakangas wrote:
>> I still don't think this worth it to change the hook function's signature
>> for this. Even though it's not a big deal for external modules to adapt,
>> it's not zero
On Thu, May 18, 2017 at 2:37 AM, Heikki Linnakangas wrote:
> I still don't think this worth it to change the hook function's signature
> for this. Even though it's not a big deal for external modules to adapt,
> it's not zero effort either. And it's not that much nicer to us.
I
On 05/15/2017 07:03 AM, Noah Misch wrote:
On Thu, May 11, 2017 at 10:08:30AM +0900, Michael Paquier wrote:
On Wed, May 10, 2017 at 10:22 PM, Michael Paquier
wrote:
On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote:
Heikki Linnakangas
On Thu, May 11, 2017 at 10:08:30AM +0900, Michael Paquier wrote:
> On Wed, May 10, 2017 at 10:22 PM, Michael Paquier
> wrote:
> > On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote:
> >> Heikki Linnakangas writes:
> >>> Also note
On Wed, May 10, 2017 at 10:22 PM, Michael Paquier
wrote:
> On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> Also note that changing the signature check_password_hook_type would
>>> break any
On Wed, May 10, 2017 at 5:58 PM, Heikki Linnakangas wrote:
> On 05/10/2017 08:01 AM, Michael Paquier wrote:
>
>> On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran
>> wrote:
>>
>>> Following recent removal of support to store password in plain
On Wed, May 10, 2017 at 10:01 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Also note that changing the signature check_password_hook_type would
>> break any external modules that use the hook. Removing
>> PASSWORD_TYPE_PLAINTEXT will do that too,
Heikki Linnakangas writes:
> Also note that changing the signature check_password_hook_type would
> break any external modules that use the hook. Removing
> PASSWORD_TYPE_PLAINTEXT will do that too, because any password hook
> function would use that constant (see e.g.
On 05/10/2017 08:01 AM, Michael Paquier wrote:
On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran
wrote:
Following recent removal of support to store password in plain text,
modified the code to
1. Remove "PASSWORD_TYPE_PLAINTEXT" macro
2. Instead of using
On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran
wrote:
> Following recent removal of support to store password in plain text,
> modified the code to
>
> 1. Remove "PASSWORD_TYPE_PLAINTEXT" macro
> 2. Instead of using "get_password_type" to retrieve the
Hi All,
Following recent removal of support to store password in plain text,
modified the code to
1. Remove "PASSWORD_TYPE_PLAINTEXT" macro
2. Instead of using "get_password_type" to retrieve the encryption method
AND to check if the password is already encrypted or not, modified the code
to
a.
14 matches
Mail list logo