On Wed, Mar 16, 2016 at 9:49 PM, Shulgin, Oleksandr <oleksandr.shul...@zalando.de> wrote: > On Tue, Mar 15, 2016 at 7:23 PM, David Steele <da...@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.harib...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers