Re: Removal of plaintext password type references

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Vaishnavi Prabakaran <vaishnaviprabakaran(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removal of plaintext password type references
Date: 2017-05-10 13:22:28
Message-ID: CAB7nPqR3qbbABubQky+8q=xJO=L6TzQ5qZLCdKk4dTv7KoGaUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 10, 2017 at 10:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> 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. contrib/passwordcheck). If we
>> were to change the signature, I'd actually like to simplify it by
>> removing the password_type parameter altogether. The hook function can
>> call get_password_type() on the password itself to get the same
>> information. But it's not worth changing the API and breaking external
>> modules for that.

Ahah. I just had the same thought before reading this message.

> FWIW, I think we've never hesitated to change hook signatures across major
> versions if there was a good reason for it. It seems actually rather
> unlikely that an external module interested in check_password_hook would
> not need to know about the SCRAM changes, so this case seems like it's
> easily justifiable.

My modules break every couple of months (utility hook is the last one
in date), and usually fixes are no big deals. Removing password_type
is in this category, and as long as compilation fails properly people
will be able to notice problems easily.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tushar 2017-05-10 13:27:03 'nocopy data' option is set in SUBSCRIPTION but still data is getting migrated
Previous Message Robert Haas 2017-05-10 13:19:37 Re: Declarative partitioning - another take