Re: Providing catalog view to pg_hba.conf file - Patch submission
От | Greg Stark |
---|---|
Тема | Re: Providing catalog view to pg_hba.conf file - Patch submission |
Дата | |
Msg-id | CAM-w4HN6Mq7qAGwNKhM7Uy+f0UJHZkE3zNqBXnunoGRrh5C_Sg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Providing catalog view to pg_hba.conf file - Patch submission (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
Ответы |
Re: Providing catalog view to pg_hba.conf file - Patch
submission
|
Список | pgsql-hackers |
On Mon, Jun 30, 2014 at 8:06 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote: > After sleeping on it, I realised that the code would return '{all}' for > 'all' in pg_hba.conf, but '{"all"}' for '"all"'. So it's not exactly > ambiguous, but I don't think it's especially useful for callers. Hm. Nope, it doesn't. It just says {all} regardless of whether "all" is quoted or not. This makes sense, the rules for when to quote things in pg_hba and when to quote things for arrays are separate. And we definitely don't want to start adding quotes to every token that the parser noted was quoted because then you'll start seeing things like {"\"all\""} and {"\"database with space\""} which won't make it any easier to match things. I'm not sure adding a separate column is really the solution either. You can have things like all,databasename (which is the keyword "all" not a database "all). Or more likely something like sameuser,bob or even things like replication,all. I'm thinking leaving well enough alone is probably best. It's not perfect but if a user does have a database named "all" or "replication" or a user named "sameuser" or "samerole" then it's not like pg_hba_settings crashes or anything, it just produces information that's hard to interpret and the response might just be "don't do that". The only other option I was pondering was using a jsonb instead of an array. That would give us more flexibility and we could have a json array that contained strings and objects representing keywords. But most hba files consist *mostly* of singleton keywords, so the result might be kind of cumbersome. -- greg
В списке pgsql-hackers по дате отправления: