On 09/12/13 18:00, Robert Haas wrote:
On Fri, Dec 6, 2013 at 10:28 PM, Álvaro Hernández Tortosa <a...@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 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.
Thanks for your detailed explanation, Robert. I think that since the
comments are the problem, they should be part of the data structure that
holds the parameter (setting). That way comments would be easily
parseable, not for a INI file (which doesn't allow for these kind of
data structures) but definitely for XML (note that I'm not suggesting to
use XML).
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.
I agree that what you suggested is a machine-editable format, so I
think it's great. I would not care about SGML comments, though. If this
is for programs to use it too, I see no problem on the "verbosity" of
having uncommented all the parameters with all their associated
metainformation.
However, you think it's ugly and verbose. It definitely is (specially
XML, I'd go a different route) but as I said in a previous email: if it
would help regular postgresql users as: (1) it makes it easier to create
config tools, but (2) also helps them providing them much more
information on how to configure manually, why not sacrifice that
verbosity? Is it that bad?
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
I completely understand that. In order to explore whether the approach
I'm suggesting works or not, I'm going to work on a POC of a sample
configuration file, structured in the way I have been describing, and a
GUI and CLI tool (POC!) to use it. I'll get back to the list with it, to
check whether it may make any sense.
Thanks!
aht
--
Álvaro Hernández Tortosa
-----------
NOSYS
Networked Open SYStems
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
