Re: password_encryption default - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: password_encryption default
Date
Msg-id 20200529132214.GM6680@tamriel.snowman.net
Whole thread Raw
In response to Re: password_encryption default  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: password_encryption default
Re: password_encryption default
List pgsql-hackers
Greetings,

* Jonathan S. Katz (jkatz@postgresql.org) wrote:
> On 5/29/20 3:33 AM, Michael Paquier wrote:
> > On Thu, May 28, 2020 at 02:53:17PM +0200, Peter Eisentraut wrote:
> >> More along these lines: We could also remove the ENCRYPTED and UNENCRYPTED
> >> keywords from CREATE and ALTER ROLE.  AFAICT, these have never been emitted
> >> by pg_dump or psql, so there are no concerns from that end.  Thoughts?
> >
> > +0.5.  I think that you have a good point about the removal of
> > UNENCRYPTED (one keyword gone!) as we don't support it since 10.  For
> > ENCRYPTED, I'd rather keep it around for compatibility reasons for a
> > longer time, just to be on the safe side.
>
> By that logic, I would +1 removing ENCRYPTED & UNENCRYPTED, given
> ENCRYPTED effectively has no meaning either after all this time too. If
> it's not emitted by any of our scripts, and it's been effectively moot
> for 4 years (by the time of PG14), and we've been saying in the docs "he
> ENCRYPTED keyword has no effect, but is accepted for backwards
> compatibility" I think we'd be safe with removing it.
>
> Perhaps a stepping stone is to emit a deprecation warning on PG14 and
> remove in PG15, but I think it's safe to remove.

We're terrible about that, and people reasonably complain about such
things because we don't *know* we're gonna remove it in 15.

I'll argue again for the approach I mentioned before somewhere: when we
commit the patch for 14, we go back and update the older docs to note
that it's gone as of v14.  Deprecation notices and other such don't work
and we instead end up carrying legacy things on forever.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: feature idea: use index when checking for NULLs before SET NOT NULL
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: password_encryption default