On Tue, Aug 6, 2013 at 10:33:20AM -0700, Josh Berkus wrote: > 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 wish I had good news to "say well". ;-) > 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. One of the traps here is that while it makes it easier, it also could trap the user if they don't have the knowledge to fix a problem because would need to acquire the knowledge while they are trying to fix the problem, rather then while they are making the initial change. > (2) Enabling DBAAS services to give users limited control over settings. Right. This could be accomplished by giving users a function API for certain features, and then marking the function as SECURITY DEFINER. However, I am unclear how to do this in a generic way. Once neat idea would be to have a lookup table define which setting the administrator wishes to allow for non-superusers. If adminpack has an API to change postgresql.conf, it would be easy to create a function with SECURITY DEFINER permissions that SET lookup-allowed values in postgresql.conf. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
