On 30/08/2023 03:21 CEST Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> I am somewhat surprised too, but it has been like that since commit 8ae0d476a9
> in 2005.
Yeah, unlikely to find out why after 18 years.
> The code is pretty clear about that:
>
> if (superuser == TRI_YES)
> {
> /* Not much point in trying to restrict a superuser */
> createdb = TRI_YES;
> createrole = TRI_YES;
> }
>
> I would say that changing that long standing behavior would cause more harm
> than benefit.
Sure, but it sounds like a reasonable change for a future major release.
> First, as the code says, it doesn't make a lot of difference. And who knows,
> perhaps someone somewhere creates superusers, later changes them to NOSUPERUSER
> and expects CREATEDB and CREATEROLE to be set after that.
Just realized that the bootstrap user has all attributes even though not needed
as a superuser. Maybe that's the reason for createuser's behavior. But why
only CREATEDB and CREATEROLE then?
> If anything, we could add something to the documentation.
Anyway, I prepared a patch for the docs. But I'm not sure if the description
should still read "There is no effective difference between creating users via
this utility and via other methods for accessing the server."
--
Erik