Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
От | Greg Smith |
---|---|
Тема | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Дата | |
Msg-id | 5145E9E3.7090200@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] (Boszormenyi Zoltan <zb@cybertec.at>) |
Ответы |
Re: Re: Proposal for Allow postgresql.conf values to be
changed via SQL [review]
|
Список | pgsql-hackers |
On 3/14/13 4:48 PM, Boszormenyi Zoltan wrote: > The attached patch makes > SET PERSISTENT transactional and uses one setting per file. > It uses the currently existing parsing and validating code > and because of this, the patch is half the size of v12 from Amit. That's not a completely fair comparison, because you lost all the regression testing code too. This does look like a usefully tighter implementation in a few ways, so good progress on that. I still can't see any reason to prefer this "one setting per file" idea. As I see it, that is pushing the complexity towardthe user in a bad way, seemingly just so it's easier to implement. Most of my customers now use tools like Puppet to manage their PostgreSQL configuration. I do not want to have this conversation: Greg: "You can use SET PERSISTENT to modify settings instead of changing the postgresql.conf" User: "That's useful. How do we adjust Puppet to make sure it picks up the changes?" Greg: "You just scan this config directory and add every file that appears in there! Each setting will be in its own file." User: "<shocked look> It creates new files? That isn't going to fit into our version control approach easily. Can we disable this feature so no one accidentally uses it?" I'm not exaggerating here--"one setting per file" makes this feature less than useless to me. It becomes something where I will have to waste time defending against people using it. I'd prefer to not have this at all than to do it that way. That we're breaking these settings off into their own file, instead of trying to edit the postgresql.conf, to me is a pragmatic trade-off to keep the implementation from being really complicated. It's also a step forward in a larger series for how to improve configuration management. Just because that change introduces an entire directorybeing scanned, I don't see that as an excuse to clutter it with a long list of files too. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: