> hjp-pgsql@hjp.at wrote:
>
>> ronljohnsonjr@gmail.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
thechange into the repo, this is what people will do. When doing it the "proper" way is much more complicated than just
fudgingit, 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’lltake 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
letsyou 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
isallowed... ».) 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
functionfor a particular new use case. But there are still plenty of such cases where opinions will vary and where each
preferencecan 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
tellsme 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
mostoften to happen as an expedient because the recommended practice requires too much effort. The general
second-orderadvice for such scenarios is to write down the rationale and to offer it up for peer review. And if there
areno peers who care, then all bets are anyway off...
