Re: Hostnames in pg_hba.conf

But once there, it seems clear that packing hostnames or netmasks onto one line is just ugly and hard to manage. I'd like to see this extended to any of the many ways to allow hostnames to be specified one per line. For example:

set tool_servers {
    127.0.0.1/32
    ::1/128
    1.2.3.4/32
    1.2.3.5/32
}

host DATABASE USER $tool_servers md5

The above features easy parsing capability.

Of course, then I'll ask for the ability to simplify specifying multiple databases:

set databases {
    db1
    db2
}

set users {
    user1
    user2
}

host $databases $users $tool_servers md5

Sorry... :-)

I think wildcards are interesting, but I have yet to see an actual use case other than "it's cool and very generalized". In my mind (tell me if I'm wrong), the most common type of PostgreSQL authentication setup is within a local network within an organization. There, you either authorize an entire subnet ("the entire server park" or "all client PCs") or you authorize specific hosts (single IP address). The wildcard case is for replacing the first case, but for that case, subnets are usually just fine. I'm trying to target the second case here.

The user case would be an organization with nodes all over the IP space, that wants to manage configuration from a single place. DNS would be that single place of choice. If moves trust from "trust the netmasks to be kept up-to-date" to "trust that DNS will be kept up-to-date". Since DNS has important reasons to be up-to-date, it's a pretty safe bet that DNS is equal or more up-to-date than pg_hba.conf hard coded netmasks. It makes sense, but it can be a later use case. It doesn't have to be in version 1.