On 10/2/16, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Mon, Oct 3, 2016 at 3:25 PM, Vitaly Burovoy <vitaly.buro...@gmail.com>
>> I guess for ability to use filtering like:
>> SELECT * FROM pg_hba_rules WHERE options->>radiusserver LIKE
>> 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):
options->>radiusserver = ANY(ARRAY['a.example.com', 'g.example.com'])
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
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).
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: