On Thu, Sep 8, 2022 at 5:46 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Jacob Champion <jchamp...@timescale.com> writes: > > I think you're going to have to address backwards compatibility > > concerns. Today, I can create a role named "/a", and I can put that > > into the HBA without quoting it. I'd be unamused if, after an upgrade, > > my rule suddenly matched any role name containing an 'a'. > > Meh ... that concern seems overblown to me. I guess it's possible > that somebody has an HBA entry that looks like that, but it doesn't > seem very plausible. Note that we made this exact same change in > pg_ident.conf years ago, and AFAIR we got zero complaints.
What percentage of users actually use pg_ident maps? My assumption would be that a change to pg_hba would affect many more people, but then I don't have any proof that there are users with role names that look like that to begin with. I won't pound the table with it. > > Speaking of partial matches, should this feature allow them? Maybe > > rules should have to match the entire username instead, and sidestep > > the inevitable "I forgot to anchor my regex" problems? > > I think the pg_ident.conf precedent is binding on us here. If we > make this one work differently, nobody's going to thank us for it, > they're just going to wonder "did the left hand not know what the > right hand already did?" Hmm... yeah, I suppose. From the other direction, it'd be bad to train users that unanchored regexes are safe in pg_hba only to take those guardrails off in pg_ident. I will tuck that away as a potential behavior change, for a different thread. Thanks, --Jacob