Re: Allow file inclusion in pg_hba and pg_ident files
От | Julien Rouhaud |
---|---|
Тема | Re: Allow file inclusion in pg_hba and pg_ident files |
Дата | |
Msg-id | 20220226062715.trm6e7nhyvhc7qlc@jrouhaud обсуждение исходный текст |
Ответ на | Re: Allow file inclusion in pg_hba and pg_ident files (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Allow file inclusion in pg_hba and pg_ident files
|
Список | pgsql-hackers |
Hi, On Sat, Feb 26, 2022 at 03:04:43PM +0900, Michael Paquier wrote: > On Wed, Feb 23, 2022 at 09:44:58AM -0800, Nathan Bossart wrote: > > On Wed, Feb 23, 2022 at 12:59:59PM +0800, Julien Rouhaud wrote: > >> 0001 adds a new pg_ident_file_mappings view, which is basically the same as > >> pg_hba_file_rules view but for mappings. It's probably already useful, for > >> instance if you need to tweak some regexp. > > > > This seems reasonable. > > Interesting. One can note that hba.c is already large, and this makes > the file larger. I'd like to think that it would be better to move > all the code related to the SQL functions for pg_hba.conf and such to > a new hbafuncs.c under adt/. Would that make sense? I'm fine with it. Assuming that you meant to move also the underlying functions that goes with it (fill_hba_line and such), that would end up removing about 15% of hba.c (after applying 0001, 0002 and 0003). Note that in order to do so we would need to expose quite a lot more about hba internals, like tokenize_file() and parse_hba_line(), along with structs HbaToken and TokenizedLine.
В списке pgsql-hackers по дате отправления: