Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf

Поиск
Список
Период
Сортировка
От Jelte Fennema
Тема Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf
Дата
Msg-id CAGECzQQ_h_-kUg_xy=mm8b6wQ=TSMV=-5h37T32=qODxi+GOMA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf  (Michael Paquier <michael@paquier.xyz>)
Список 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?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Blocking execution of SECURITY INVOKER
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Blocking execution of SECURITY INVOKER