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
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? |