On 13.07.2023 18:01, Tom Lane wrote:
> The idea with that, IMO, is to do something at least minimally sane
> if there's a bogus role OID in pg_auth_members. With plain joins,
> the output row would disappear and you'd have no clue that anything
> is wrong. With left joins, you get a row with a null column and
> there's reason to investigate why.
>
> Since such a case should not happen in normal use, I don't think it
> counts for discussions about compactness of output. However, this
> is also an argument for using a plain not left join between pg_roles
> and pg_auth_members: if we do it as per the earlier patch, then
> nulls in the output are common and wouldn't draw your attention.
> (Indeed, I think broken and not-broken pg_auth_members contents
> would be indistinguishable.)
It reminds me about defensive programming practices.
That's great, thanks for explanation.
> That does not seem right. Is it impossible for pam.set_option
> to be false? Even if it is, should this code assume that?
For versions before 16, including one role to another automatically
gives possibility to issue SET ROLE.
IMO, the only question is whether it is correct to show IMPLICIT and
SET options in versions where they are not actually present
in pg_auth_members, but can be determined.
--
Pavel Luzanov
Postgres Professional: https://postgrespro.com