On Mon, Jun 30, 2014 at 8:06 AM, Abhijit Menon-Sen <a...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
