@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.
