On Fri, Mar 6, 2015 at 3:11 AM, Peter Eisentraut <peter_e@gmx.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.