>Regarding removal of inheriting superuser role needs broader discussion. There
>must be a reason why it was done and removing this feature may impact existing
>use cases.
The reason behind the current behaviour is almost irrelevant, the fact is that
this is the way that it works and has done s
- Forgot to mention, is_superuser of roles table cannot be altered as it is
just showing what is persisted in the table. We can think about changing super
column of LIST ROLES command instead.
- Regarding change of the underlying state while we retrieve superusers info, I
believe we do not need
- In the example you listed below, role2 doesn’t lose superuser status because
it was created as a superuser (based on the point 2). The scenario you
mentioned can happen if role2 was initially not created as a superuser. When we
create a role as a superuser, we persist that info in roles table,
Don’t know why is_superuser was not set to true for acquired superusers. Now if
we change it, may break existing tools/scripts/understanding of customers, so
do we want to update current understanding of is_superuser column or introduce
a new column or option instead?
> On Feb 29, 2024, at 11:
