I wrote:
> I'm still not very happy about the choice of view name ...
After looking over this thread again, I think that we should go with
pg_file_hba_rules or perhaps pg_hba_file_rules. I see that options
like that were discussed and rejected earlier, but I feel the arguments
against were based on false premises. I think we need "file" in the
name because:
1. It makes the analogy to the pg_file_settings view clearer.
2. It emphasizes that what you see in the view is the contents of
the disk files, not necessarily the active rules.
3. It leaves the door open to use "pg_hba_rules" as the name of some
future view that *does* show the active rules, analogously to pg_settings
which does show the active GUC settings.
I realize that there's no very convenient way to implement a true
active-auth-rules view right now, but it's not hard to see how that
could be fixed if we were motivated to do so. One simple way would
be for the postmaster, any time it had successfully loaded the hba
file, to write out some representation of the parsed data into an
"active auth rules" file. I doubt anyone would bother if the only
application were an active-rules view, but there's at least one
other reason to do this, which is that we could make the HBA stuff
work the same on Windows as it does elsewhere. Right now, since
new EXEC_BACKEND backends must read the HBA files for themselves,
Windows does not have the property that pg_hba.conf is read only
at SIGHUP --- break the file with some fat-fingered editing, and
new connections begin to fail instantly. But if new backends
always read a postmaster-written file, then the behavior would be
the same as it is on Unix.
regards, tom lane