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.



Álvaro Hernández Tortosa

Networked Open SYStems

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to