Re: Providing catalog view to pg_hba.conf file - Patch submission
От | Peter Eisentraut |
---|---|
Тема | Re: Providing catalog view to pg_hba.conf file - Patch submission |
Дата | |
Msg-id | 5547DB0A.2020904@gmx.net обсуждение исходный текст |
Ответ на | Re: Providing catalog view to pg_hba.conf file - Patch submission (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Providing catalog view to pg_hba.conf file - Patch submission
|
Список | pgsql-hackers |
On 5/1/15 12:33 PM, Andres Freund wrote: > On 2015-04-08 19:19:29 +0100, Greg Stark wrote: >> I'm not sure what the best way to handle the hand-off from patch >> contribution to reviewer/committer. If I start tweaking things then >> you send in a new version it's actually more work to resolve the >> conflicts. I think at this point it's easiest if I just take it from >> here. > > Are you intending to commit this? It still looks quite dubious to me. The more I test this, the more fond I grow of the idea of having this information available in SQL. But I'm also growing more perplexed by how this the file is mapped to a table. It just isn't a good match. For instance: What is keyword_databases? Why is it an array? Same for keyword_users. How can I know whether a given database or user matches a keyword? What is compare_method? (Should perhaps be keyword_address?) Why is compare method set to "mask" when a hostname is set? (Column order is also a bit confusing here.) I'd also like options to be jsonb instead of a text array. Ultimately, I don't see how this is better than just showing the raw file. I don't see a sensible way to compute answers to questions such as "What is the authentication method for user X from IP address Y." If I can't do that, what's the point of having a processed version?
В списке pgsql-hackers по дате отправления: