On 04/12/13 20:44, Peter Eisentraut wrote:
On 12/4/13, 2:02 PM, Álvaro Hernández Tortosa wrote:
So optional fields are either purely optional (i.e., only for tools
that want to use them; everyone else may ignore, but preserve, them) and
some other are just NULLABLEs, depending on the parameter).
But my point stands: If it's optional, you can't rely on it, if it's
required, people will object because they don't more junk in their
OK, I get what you say. My bad, I called "optional" what it is either
"optional" (reserved for extension fields) or NULLABLE (fields that may
be absent, meaning that they are NULL).
But what matters are the required fields. You say they add "junk" to
the config file. I understand what you say, but is it really junk? Is it
In return for this extra information, we:
- Provide users with more help (information) to help them configure
postgres (which is no easy task, specially for newcomers).
- Help and encourage app developers to create both GUI tools for easier
postgresql configuration and automatic or semi-automatic configuration
- Make it way easier to change postgresql parameters persistently from a
The tradeoff seems quite positive to me. I see no strong reasons why
not do it... am I missing something?
But I think this is solving the wrong problem. The metadata is already
available via postgres --describe-config.
I think that doesn't solve any of the above benefits we would get from
a programmable postgresql format such as the one I have described.
Álvaro Hernández Tortosa
Networked Open SYStems
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: