Re: Providing catalog view to pg_hba.conf file - Patch submission - Mailing list pgsql-hackers

* Haribabu Kommi (kommi.haribabu@gmail.com) wrote:
> On Tue, May 5, 2015 at 6:48 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > 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.
>
> 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?

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.

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.
Thanks!
    Stephen