On 08/06/2013 05:29 AM, Bruce Momjian wrote:
> Let's look at the problems:
>
> * remote users can lock themselves out of the server
> * interconnected GUC variables are complex to change
> * need a way to disable this feature
>
> Given the above, I am not sure I see a way forward for ALTER SYSTEM SET.
> One compromise that avoids the problems above would be to have a limited
> feature called ALTER LOG SET that only controls logging parameters, but
> I am not sure there is enough use-case there.
>
> This is not a zero-cost feature as we would be giving people _two_ ways
> to configure Postgres, and two ways to find a fix if it is broken, so we
> have to have a clear win to implement this. Also, if you have broken
> the system via ALTER SYSTEM SET, you might need to edit flat files to
> fix it, adding further complexity and limitations if someone only knows
> the SQL method of configuration. Given that, and the problems above, I
> reluctantly just don't see how this features moves us forward.
Well said.
I'd like to look at use cases, and let's see how ALTER SYSTEM SET
addresses or doesn't address these use cases. I'd really like it if
some other folks also posted use cases they know of.
(1) Making is easier for GUIs to manage PostgreSQL settings.
(2) Enabling DBAAS services to give users limited control over settings.
(3) Making the "initial developer experience" better by not requiring
hand-editing of configuration files to play with settings.
(4) Making it easier to write automated testing scripts which test
changes to settings.
(5) Enabling new ways of writing Puppet/Chef/etc. scripts, which can
check a setting before changing it.
For the current patch, it fullfills these use cases as follows:
(1) works, but is ALSO one of the critical problems with the feature.
(2) does not work for this purpose.
(3) works for this purpose.
(4) works for this purpose.
(5) works for this purpose, although it's unclear if it's actually wanted.
Others?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
