On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be rather useful to
augment pg_hba.conf to filter based on appname.
For my "pet" case, that would mean one might let "slon" and "slonik"
(Slony appname values) in, whilst keeping other appnames out, during a
system maintenance.
It's debatable whether or not that's more useful than filtering on the
basis of user names, which are likely to be pretty nearly isomorphic
to appnames.
Due to the near-isomorphism, I would not be comfortable trying to
claim that this is anywhere near essential.
During upgrade, I expect that we'd want everything but the upgrade
process locked out, including some backend-ish processes such as
autovacuum. That doesn't have quite the same "feel" as pg_hba.conf,
which also piques my "not totally comfortable" with this being a
pg_hba.conf thing.
That doesn't mean the idea's useless in and of itself, nor that
there's not some useful adaption to be made.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"