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
