On 2014-02-14 10:19:30 -0500, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Having @include and directory.d-style capabilities for pg_hba.conf *and*
> > pg_ident.conf would make managing larger environments much better.
>
> I'm a little suspicious of this, mainly because pg_hba searching is
> necessarily linear (and none too cheap per-entry). I think anyone
> who tries to use a set of entries large enough to really need multiple
> files is going to have pain.
I don't think big hba files should be the primary motivator for a
feature like this. What I have seen is that people want a couple entries
that grant local access to maintenance scripts and
root/postgres. Additionally they want to have a *few* for every
application that runs on the same cluster and another additional couple
of entries allowing access to a limited number of replicas.
It's not too hard to script this, simply have a pg_bha.d directory whose
contents are concatenated in an alphabetic order resulting in a combined
file. But that's clearly inferior to builtin support for that because
the error reporting obviously won't be as good and it's not possible to
nicely hook this into reloads and such.
I wonder if the linear search could be improved a bit by separating
database specific entries from database independent ones as the setups
with large number of entries mostly had lots of database specific
rules. It would probably be nontrivial to guarantee the sequential
lookup order, but it should be possible.
> I'd be interested to see a real use-case where those things aren't
> an adequate substitute for a pg_hba rule set that's too large to
> fit conveniently in one file. Maybe we could identify another
> pg_hba abstraction technique we need to support.
That additionally very well might be. The biggest thing I have seen is
a) the inability to restrict access based on outside group membership
when using ldap, b) the inability to grant membership in groups from
outside of pg.
Greetings,
Andres Freund
