Re: pg_hba_lookup function to get all matching pg_hba.conf entries

On Wed, Mar 16, 2016 at 9:49 PM, Shulgin, Oleksandr
<oleksandr(dot)shulgin(at)zalando(dot)de> wrote:
> On Tue, Mar 15, 2016 at 7:23 PM, David Steele <david(at)pgmasters(dot)net> wrote:
>>
>> On 3/3/16 12:16 AM, Haribabu Kommi wrote:
>> > On Fri, Feb 5, 2016 at 2:29 PM, Haribabu Kommi
>> > <kommi(dot)haribabu(at)gmail(dot)com> wrote:
>> >>
>> >> This patch needs to be applied on top discard_hba_and_ident_cxt patch
>> >> that is posted earlier.
>> >
>> > Here I attached a re-based patch to the latest head with inclusion of
>> > discard_hba_ident_cxt patch for easier review as a single patch.
>>
>> Alex, Scott, do you have an idea of when you'll be able to review this
>> new version?
>
>
> The new version applies with some fuzziness to the current master and
> compiles cleanly.
>
> Some comments:
>
> +/* Context to use with hba_line_callback function. */
> +typedef struct
> +{
> + MemoryContext memcxt;
> + TupleDesc tupdesc;
> + Tuplestorestate *tuple_store;
> +} HbalineContext;
>
> Rather "with *lookup_hba_line_callback*", as hba_line_callback() is a
> generic one.

Fine. I will change the function and context names.

> + line_number | mode | type | database | user_name | address |
> netmask | hostname | method | options | reason
> +-------------+---------+-------+----------+-----------+-----------+-----------------------------------------+----------+--------+---------+--------------------------
> + 84 | skipped | local | {all} | {all} | |
> | | trust | {} | connection type mismatch
> + 86 | skipped | host | {all} | {all} | 127.0.0.1 |
> 255.255.255.255 | | trust | {} | IP
> address mismatch
> + 88 | matched | host | {all} | {all} | ::1 |
> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | | trust | {} |
>
> Hm... now I'm not sure if we really need the "mode" column. It should be
> clear that we skipped every line that had a non-NULL "reason". I guess we
> could remove "mode" and rename "reason" to "skip_reason"?

Ok. Lets hear from others also regarding the same.

> Still remains an issue of representing special keywords in database and
> user_name fields, but there was no consensus about that though.

How about adding keyword_database and keyword_user columns to listing
out the keywords. These columns will be populated only when the hba line
contains any keywords.

Regards,
Hari Babu
Fujitsu Australia