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> > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers