* 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
signature.asc
Description: Digital signature
