* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > The OPs people are the ones that will be upset with this because the DBAs > > will be modifying configs which OPs rightfully claim as theirs. > > If that's the problem you want to solve, there's no technical solution > that will put you at ease. That's a people and trust problem.
I really just don't buy that- I've already put forward suggestions for how to deal with it, but no one here seems to understand the distinction. Modifying listen_addresses through ALTER SYSTEM is akin to ISC/bind allowing changes to its listen_addresses equivilant through dynamic DNS updates. Would it be possible to implement? Sure. Does it make any sense? Certainly not. > I don't think typical (or less typical) organisation should drive our > technical choices too much, and I'm pretty confident they didn't in the > past: pg_hba.conf is a file not because it's meant for this or that team > but because it makes sense technically to manage the settings to allow > using some resources *outside* of said resources. I'm all for moving pg_hba.conf into the database properly, actually. We already handle permissions and user access in the DB and that's one of the DBA's responsibilities. The same goes for pg_ident.conf. > We currently have no way that I know of to disable ALTER ROLE SET and > ALTER DATABASE SET effects, why do we need to provide that feature for > ALTER SYSTEM SET so much? Because we've got crap mixed into postgresql.conf which are bootstrap configs needed to get the system started. Those things, in my view anyway, fall much more into the category of "resources which should be managed outside the database" than pg_hba.conf. Thanks, Stephen
Description: Digital signature