Re: HBA files w/include support?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Jerry Sievers <gsievers19(at)comcast(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HBA files w/include support?
Date: 2014-02-14 15:19:30
Message-ID: 26823.1392391170@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)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.

We already have various methods for making one pg_hba entry do the
work of many; for instance, IP-subnet entries, wildcards, and role
references. And you can use database CONNECT privilege grants as
another substitute for fine-grained pg_hba entries.

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.

In short: I suspect this approach may be fixing the wrong thing.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-02-14 15:26:07 Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
Previous Message Fabrízio de Royes Mello 2014-02-14 14:49:49 Re: HBA files w/include support?