Re: Providing catalog view to pg_hba.conf file - Patch submission

On Fri, Mar 6, 2015 at 3:11 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> The point is, it should be one or the other (or both), not something in
> the middle.
>
> It's either a textual representation of the file or a semantic one. If
> it's the latter, then all user names, group names, and special key words
> need to be resolved in some way that they cannot be confused with
> unfortunately named user names. And there needs to be a way that we can
> add more in the future.
>

I think what we have here is already a good semantic representation. It
doesn't handle all the corner cases but those corner cases are a) very
unlikely and b) easy to check for. A tool can check for any users starting
with + or named "all" or any databases called "sameuser" or "samerole". If
they exist then the view isn't good enough to reconstruct the raw file. But
they're very unlikely to exist, I've never heard of anyone with such things
and can't imagine why someone would make them.

The view as is is useful for everyone. Someone who wants to write a tool
can reconstruct the file as long as none of the problematic names exist in
the database. Someone who wants to run audits can run queries to see what
users have access to or check the permissions on a database and do simple
comparisons to check for whatever they want to check for.

If we change it to be 100% unambiguous then it will be cumbersome to work
with. The view will have 5 columns instead of 2 dedicated to users and
databases. It will be much harder for humans to read, and for people
writing code they'll have to check three columns for matches. It just seems
like a lot of busywork to make it less useful.

Attached are two copies of the view, one as is today and one with the
keywords and recursive elements broken out.

Also, fwiw as far as adding more in the future -- breaking the keywords out
into a separate column wouldn't interfere with that but if we want to
include any additional syntax like + then it will require additional
columns. That would actually be less flexible for future changes.

I'm inclined to commit this as is.

--
greg