Re: Providing catalog view to pg_hba.conf file - Patch submission

On Fri, May 15, 2015 at 11:24 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Haribabu Kommi (kommi(dot)haribabu(at)gmail(dot)com) wrote:
>> On Tue, May 5, 2015 at 6:48 AM, Peter Eisentraut <peter_e(at)gmx(dot)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