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.shulgin@zalando.de> wrote:
> On Tue, Mar 15, 2016 at 7:23 PM, David Steele <david@pgmasters.net> wrote:
>>
>> On 3/3/16 12:16 AM, Haribabu Kommi wrote:
>> > On Fri, Feb 5, 2016 at 2:29 PM, Haribabu Kommi
>> > <kommi.haribabu@gmail.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