Re: password_rollover_time like Oracle

> On Jun 20, 2024, at 10:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> I can see that causing problems if you want to store CURRENT_USER in the
> database, perhaps for auditing. I guess you could call it user4_login12
> and keep incrementing the login number, but that seems cumbersome.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us <mailto:bruce(at)momjian(dot)us>> https://momjian.us <https://momjian.us/>
> EDB https://enterprisedb.com <https://enterprisedb.com/>
>
> Only you can decide what is important to you.

I don’t think it’s too much of an issue for auditing as it’s same name with an embedded date code; however, I do think that changing a password every other month is cumbersome busy work and there are better ways to secure the account. The problem I’ve seen with this type of solution is the application owners would commonly forget to update password information and then the application would stop working causing a scramble to update the credentials. Then there is the account management itself, dropping expired users and creating new users for the upcoming month.