@Michael > Anyway, it is a bit confusing to see a patch touching parts of the > ident code related to the system-username while it claims to provide a > mean to shortcut a check on the database-username.
That's totally fair, I attached a new iteration of this patchset where this refactoring and the new functionality are split up in two patches. > That seems pretty dangerous to me. For one, how does this work in > cases where we expect the ident entry to be case-sensitive, aka > authentication methods where check_ident_usermap() and check_usermap() > use case_insensitive = false? I'm not sure if I'm understanding your concern correctly, but the system username will still be compared case sensitively if requested. The only thing this changes is that: before comparing the pg_role column to the requested pg_role case sensitively, it now checks if the value of the pg_role column is lowercase "all". If that's the case, then the pg_role column is not compared to the requested pg|role anymore, and instead access is granted. @Isaac > is there a reason why pg_ident.conf can't/shouldn't be replaced by a system > table? I'm not sure of the exact reason, maybe someone else can clarify this. But even if it could be replaced by a system table, I think that should be a separate patch from this patch.
v2-0001-Rename-token-to-systemuser-in-IdentLine-struct.patch
Description: v2-0001-Rename-token-to-systemuser-in-IdentLine-struct.patch
v2-0002-Support-using-all-for-the-db-user-in-pg_ident.con.patch
Description: v2-0002-Support-using-all-for-the-db-user-in-pg_ident.con.patch
