Hi there!
I've been reading several threads debating about the format of
postgresql.conf and improvements to it (like "Overhauling GUCS" [1] or
"Proposal for Allow postgresql.conf values to be changed via SQL" [2]).
Trying to summarize that in my own opinion, I think that the current
file format has some problems/limitations:
1) It exposes little information to help users configure postgres.
It has comments, but they are not consistent on the information they
give about the parameters. And they don't expose as much information as
you may find in pg_settings, nor they include extra information, such as
the param's doc URL.
2) It discourages the creation of both GUI tools for configuring
postgresql.conf and auto-tunning tools.
Parsing and writing programmatically the current config file may seem
easy at first, but has been reported to be a daunting task. There isn't
a "standard" for the comments, and hence they're really hard to parse
and write them. There isn't either a way of classifying (grouping)
the parameters by concepts such as pg_settings.category or other
user-oriented criteria, like (newbie, advanced, expert), for example.
3) There is no support for changing parameters persistently from a
postgresql connection.
This is a feature that some want, but it is hard(er) to implement if
there is no simple way of programmatically editing the config file (as
explained in #2).
4) There is no common code to parse/validate/write postgresql.conf files
that could be reused both for the server and other external tools.
IMHO, defining a new syntax for the postgreql.conf file format,
that is suitable for writing and parsing, or using an already existing,
well-known, programmatic syntax, could offer a solution for all the
problems/limitations above.
If that would be the case, I think it should be first debated
what data should be there for every parameter, and what (logical) data
structure should be used to represent it. It would be great if that
information is optionally extensible, to include extra information
--possibly ignored by postgres, but used by the external tools.
I would also suggest to require the syntax to at least be:
a) Text-based.
b) Human-friendly. Even though it may become more verbose, it should
remain easily editable by humans.
c) Easily parseable by "one-liner" cli commands such as grep, awk,
sed...
d) Optionally, an alternative to the current postgresql.conf.
Instead of replacing postgresql.conf, it may offer an alternative way of
configuring postgres. If both files are present, one of them
(postgresql.conf, for example) would take preference, being the other
one being completely ignored. Although this would create some kind of
code duplication, it would open a way for phased adoption.
e) Preferably a well-known syntax, or similar to an existing one, so
it doesn't become a new barrier for user adoption.
I know that suggesting to change --or create an alternate--
postgresql.conf file is not an easy topic, but what's your opinion? Any
comments/ideas would be appreciated :)
Regards,
aht
[1] http://www.postgresql.org/message-id/48409d1e.3070...@agliodbs.com
[2]
http://www.postgresql.org/message-id/007d01cdb5d9$a55d7ab0$f0187010$@kap...@huawei.com
--
Á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
