From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Álvaro Hernández Tortosa <aht(at)nosys(dot)es> |
Cc: | David Johnston <polobo(at)yahoo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: programmable file format for postgresql.conf |
Date: | 2013-12-09 17:00:04 |
Message-ID: | CA+TgmoaKU-mQX+pXFDhH-oyGtb8gtK6t8NvO7hz5qjBLL3V4Hg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 6, 2013 at 10:28 PM, Álvaro Hernández Tortosa <aht(at)nosys(dot)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 file and 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 for work_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
From | Date | Subject | |
---|---|---|---|
Next Message | hubert depesz lubaczewski | 2013-12-09 17:04:53 | What are multixactids? |
Previous Message | Euler Taveira | 2013-12-09 16:53:11 | Re: JSON decoding plugin |