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

From Peter Eisentraut
Subject Re: Providing catalog view to pg_hba.conf file - Patch submission
Date
Msg-id 5547DB0A.2020904@gmx.net
Whole thread Raw
In response to Re: Providing catalog view to pg_hba.conf file - Patch submission  (Andres Freund <andres@anarazel.de>)
Responses Re: Providing catalog view to pg_hba.conf file - Patch submission  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Use outerPlanState() consistently in executor code
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT syntax issues