On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan <and...@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?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
