On 10/2/16, Michael Paquier <michael.paquier@gmail.com> wrote:
> On Mon, Oct 3, 2016 at 3:25 PM, Vitaly Burovoy <vitaly.burovoy@gmail.com>
> wrote:
>> 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...
>
> With unnest() and a matching pattern, not that hard but..
I'm not a user of that feature, and I don't know how pg_hba files look
like in really big companies...
But for me filtering is more complicated than just a single comparison.
What about more complex filtering --- several radiusserver and a user(s):
WHERE options->>radiusserver = ANY(ARRAY['a.example.com', 'g.example.com']) AND options->>radiusidentifier =
ANY(ARRAY['ID_a','ID_b', 'ID_c',
'ID_d', 'ID_e']) -- or even a subquery
Again, I don't know whether it will be widely used, but in case of
multiple param_name->param_value settings (column "options") I'd like
to see native key-value store rather than array of strings (according
to POLA).
I guess you're expecting "key=value" format as they are written in the
pg_hba file (and described in the doc), but sometimes they can be
parsed and output differs from exact pg_hba records (for instance look
at "ldapurl" parameter).
--
Best regards,
Vitaly Burovoy
