| From: | Jelte Fennema <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com>, "isaac(dot)morland(at)gmail(dot)com" <isaac(dot)morland(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf |
| Date: | 2023-01-13 08:19:10 |
| Message-ID: | CAGECzQQ_h_-kUg_xy=mm8b6wQ=TSMV=-5h37T32=qODxi+GOMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Even if folks applying quotes
> would not be able anymore to replace the pattern, the risk seems a bit
> remote?
Yeah I agree the risk is remote. To be clear, the main pattern I'm
worried about breaking is simply "\1". Where people had put
quotes around \1 for no reason. All in all, I'm fine if 0003 gets
merged, but I'd also be fine with it if it doesn't. Both the risk
and the advantage seem fairly small.
> I don't see how much that's different from the recent discussion with
> regexps added for databases and users to pg_hba.conf. And consistency
> sounds pretty good to me here.
It's not much different, except that here also all and + change their meaning
(for pg_hba.conf those special cases already existed). Mainly I called it out
because I realised this discussion was called out in that commit too.
> Regexps can have commas
That's a really good reason to allow quoted regexes indeed. Even for pg_ident
entries, commas in unquoted regexes would cause the AuthToken parsing to fail.
Is there anything you still want to see changed about any of the patches?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2023-01-13 08:19:12 | Re: Blocking execution of SECURITY INVOKER |
| Previous Message | Andres Freund | 2023-01-13 08:16:41 | Re: Blocking execution of SECURITY INVOKER |