Re: RFC: programmable file format for postgresql.conf
От | Robert Haas |
---|---|
Тема | Re: RFC: programmable file format for postgresql.conf |
Дата | |
Msg-id | CA+TgmoaKU-mQX+pXFDhH-oyGtb8gtK6t8NvO7hz5qjBLL3V4Hg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: programmable file format for postgresql.conf (Álvaro Hernández Tortosa <aht@nosys.es>) |
Ответы |
Re: RFC: programmable file format for postgresql.conf
(Álvaro Hernández Tortosa <aht@nosys.es>)
|
Список | pgsql-hackers |
On Fri, Dec 6, 2013 at 10:28 PM, Álvaro Hernández Tortosa <aht@nosys.es> wrote: > I think both could be used a lot, editing directly a rich configuration > file or using a GUI tool. I'm trying to suggest supporting both. I don't really understand how changing the file format fixes anything.You could make the file an INI file or an XML fileand it would still be hard to edit programmatically, not because the current format is "hard to parse" in any meaningful sense, but because there's no way for a program to know how to make changes while preserving the comments. For example, suppose the user tries to set work_mem to 4MB.If there's an existing line in the config file forwork_mem, it's fairly plausible to think that you might just replace everything on that line, up to the beginning of any comment, with a new work_mem setting. But what if, as in the default configuration file, there isn't any such setting? A human will go and find the line that says: #work_mem = 1MB ...and delete the hash mark, and replace 1MB with 4MB. No problem! But for a computer, editing comments is hard, and kind of iffy. After all, there might be multiple lines that look like the above, and how would you know which one to replace? There could even be something like this in the file: #In our installation, because we have very little memory, it's important not to do anything silly like set #work_mem = 64MB A configuration file editor that replaces that line will corrupt the comment, because no program can be smart enough to recognize the context the way a human will. Now, we could design something that gets it right, or close enough to right, 99% of the time. But previous discussions of this issue on this mailing list have concluded that people are not willing to accept that kind of solution, which IMHO is understandable. The only kind of change that I see as possibly helpful is some format that explicitly marks which comments go with which settings. For example, suppose we did this: <setting> <name>work_mem</> <!-- <value>1MB</> --> <comment>min 64kB</> </setting> If you want to set the value, you remove the comment tags around it. And if you want to comment on the value, you can put whatever you like within the comment tags. Now, you've got a machine-editable format, assuming that people keep their comments in the <comment/> section and not inside actual SGML comments. But that's ugly and overly verbose, so meh. Generally I don't regard trying to tinker with postgresql.conf as a useful way to spend time. Many people have strong and sometimes conflicting feelings about it, making getting any consensus of any change almost impossible. And while I'm sure some die-hard will disagree with me on this, the current format, imperfect as it is, is not really all *that* bad. We all have our bones to pick with it and I certainly wouldn't have picked this exact approach myself, but we could have done far worse. If it were clear what the next logical step to make it better was, or even if it were clear that the current blew chunks, then I'd be all over putting energy into getting this fixed. But it isn't, and it doesn't, and the amount of collective energy that would need to be put into making any change here doesn't seem likely to be worth what we'd get out of it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: