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

On Mon, Mar 16, 2015 at 9:29 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Robert Haas wrote:
> > On Wed, Mar 11, 2015 at 1:32 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> > > 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.
> >
> > -1. Like Peter, I think this is a bad plan. Somebody looking at the
> > view should be able to understand with 100% confidence, and without
> > additional parsing, what the semantics of the pg_hba.conf file are.
> > Saying "those cases are unlikely so we're not going to handle them" is
> > really selling ourselves short.
>
> +1 what Robert said. I think the additional "keyword" columns are a
> good solution to the issue.
>
>
​Why not just leave the double-quoting requirements intact. An unquoted
<any> or <sameuser> (etc) would represent the special keyword while the
quoted version would mean that the name is used literally.

​Have the: "​A separate file containing [database|user] names can be
specified by preceding the file name with @" possibilities been added to
the test suite?

I'm not totally opposed to using some other quoting symbol to represent
keywords as well - like "*" (e.g., *all*). Like Greg, I'm not to keen on
the idea of adding additional keyword columns.

*Logical View - Keyword Expansion*

​My other thought was to not use the keywords at all and simply resolve
their meaning​ to actual role/database names and list them explicitly.
That would be a true logical view and allow for simple user checking by
saying: 'username' = ANY(users); without the need for ([...] OR '*any*' =
ANY(users) or similar). If going that route I guess it would behoove us to
either incorporate a "physical" view of the actual file converted to a
table or to then maybe have some kind of "tags" fields with the special
values encoded should someone want to know how the user list was
generated. In effect, the "pg_hba" view in the original file but with
actual names of users and databases instead of empty arrays.

The "sameuser" => "all" pairing is a pure physical representation in that
instance. What I would do in a logical representation is have a single
record for each user that has a database of the same name in the current
database. However, because of that limitation you either would be
duplicating information by keeping "sameuser,all" or you would have to have
a separate view representing the physical view of the file. I think having
two views, one logical and one physical, would solve the two use cases
nicely without having to compromise or incorporate too much redundancy and
complexity.

Likewise, if we know the host ip address and subnet mask the keywords
"samehost" and "samenet" should be resolvable to actual values at the time
of viewing. Though that would add the complication of multi-network
listening...

I guess a full logical view is a bit much but if we keep the same quoting
mechanics as mandated by the file then there should be no ambiguity in
terms of label meaning and whomever is looking at this stuff has to
understand about the keywords and using quote to remove the special-ness
anyway.

David J.