From: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_hba_file_settings view patch |
Date: | 2016-10-03 06:25:56 |
Message-ID: | CAKOSWNkNhn7umqE=J+LQgxFtD+aj-dNEQg2UwEeBaZUZB3o+Eg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/2/16, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> + push_jsonb_string_key(&parseState, "map");
> + push_jsonb_string_value(&parseState, hba->usermap);
> [...]
> + <row>
> + <entry><structfield>options</structfield></entry>
> + <entry><type>jsonb</type></entry>
> + <entry>Configuration options set for authentication method</entry>
> + </row>
> Why is it an advantage to use jsonb here instead of a simple array
> made of name=value? If they were nested I'd see a case for it but it
> seems to me that as presented this is just an overkill.
I guess for ability to use filtering like:
SELECT * FROM pg_hba_rules WHERE options->>radiusserver LIKE '%.example.com';
I think it would be harder if options is an array of strings...
--
Best regards,
Vitaly Burovoy
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-10-03 06:46:33 | Re: pg_hba_file_settings view patch |
Previous Message | Andrew Borodin | 2016-10-03 05:55:10 | Re: GiST penalty functions [PoC] |