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
> config file.
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
that bad?
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
tools.
- Make it way easier to change postgresql parameters persistently from a
SQL connection.
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.
Best,
aht
--
Álvaro Hernández Tortosa
-----------
NOSYS
Networked Open SYStems