Re: Seeking practice recommendation: is there ever a use case to have two or more superusers?

> hjp-pgsql(at)hjp(dot)at wrote:
>
>> ronljohnsonjr(at)gmail(dot)com wrote:
>>
>> [developers or devops folks] like to "fix" things without documenting what they did, and then, when
>> something breaks, denying they did anything (or honestly not believing that
>> whatever "trivial" thing they did could any major or deliterious impact).
>
> Which is why you want to automate deployments. When the easiest way to fix something in production is to just push the change into the repo, this is what people will do. When doing it the "proper" way is much more complicated than just fudging it, people will do the latter.

Thanks to all who offered their views on my question. It seems that different people will reach different conclusions. I’ll take this as permission to reach my own conclusion.

Software systems in general often offer some freedoms that most people think should never be exercise. For example, PG lets you define a domain that has a not null constraint on one, or more, of its data attributes. But the doc

https://www.postgresql.org/docs/current/sql-createdomain.html

tells you not to do this. (Look for « Best practice therefore is to design a domain's constraints so that a null value is allowed... ».) I was rather slow to grasp the risks that ignoring this advice brings.. But I get it now.)

At the other end of the spectrum, there’s generally accepted thinking on how to choose between a procedure or a function for a particular new use case. But there are still plenty of such cases where opinions will vary and where each preference can be defended with reasonable arguments.

I haven’t seen anything in the PG doc that warns against creating additional superusers—so I suppose that this fact tells me something. Nevertheless, I remain convinced about what I’d recommend here:

The default choice must be to allow only one superuser: the inevitable bootstrap superuser.

But I’ll concede that I should see this like many rules of recommended practice. Sometimes they get broken. This seems most often to happen as an expedient because the recommended practice requires too much effort. The general second-order advice for such scenarios is to write down the rationale and to offer it up for peer review. And if there are no peers who care, then all bets are anyway off...