On Fri, May 15, 2015 at 11:24 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: >> On Tue, May 5, 2015 at 6:48 AM, Peter Eisentraut <pete...@gmx.net> wrote: >> > 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. >> >> Thanks for your suggestion. I am not sure how to use jsonb here, i >> will study the same >> and provide a patch for the next version. > > Regarding "next version"- are you referring to 9.6 and therefore we > should go ahead and bounce this to the next CF, or were you planning to > post a "next version" of the patch today?
Yes, for 9.6 version. > This is certainly a capability which I'd like to see, though I share > Peter's concerns regarding the splitting up of the keywords rather than > keeping the same structure as what's in the actual pg_hba.conf. That > strikes me as confusing. It'd be neat if we were able to change > pg_hba.conf to make more sense and then perhaps the SQL version wouldn't > look so different but I don't think there's any way to do that. > > I discussed the patch briefing with Greg over IM, who pointed out that > keeping things just exactly as they are in the config file would mean > implementing, essentially, a pg_hba.conf parser in SQL. I can > understand that perspective, but I don't think there's really much hope > in users being able to use this view directly without a lot of effort, > regardless. We need to provide a function which takes the arguments > that our pg_hba lookup does (database, user-to-login-as, maybe system > user for pg_ident checks, optionally an IP, etc) and then returns the > record that matches. Thanks for details. I will try to come up with a view and a function by considering all the above for the next commitfest. > Apologies for not being able to provide more feedback earlier. I'll be > happy to help with all of the above and review the patch. > > Independently, I'd love to see an SQL interface to pg_ident.conf too, > where, I expect anyway, it'll be a lot simpler, though I'm not sure that > it's very useful until we also have pg_hba.conf available through SQL. Yes, Definitely I look into pg_ident also along with pg_hba. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
