On 5/29/20 9:22 AM, Stephen Frost wrote:
> 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.
Yeah, my first preference is to just remove it. I'm ambivalent towards
updating the older docs, but I do think it would be helpful.
Jonathan