Re: RFC: programmable file format for postgresql.conf

On 06/12/13 04:47, Peter Eisentraut wrote:
> On Thu, 2013-12-05 at 00:51 +0100, Álvaro Hernández Tortosa wrote:

>>
>> The tradeoff seems quite positive to me. I see no strong
>> reasons why
>> not do it... am I missing something?
>
> I don't buy your argument. You say, if we make this change, those
> things will happen. I don't believe it. You can *already* do those
> things, but no one is doing it.

What I've been trying to do is summarize what has already been
discussed here and propose a solution. You say that "you can already do
those thisngs", but that's not what I have read here. Greg Smith (cc'ed
as I'm quoting you) was explaining this in [1]:

"Right now, writing such a tool in a generic way gets so bogged down
just in parsing/manipulating the postgresql.conf file that it's hard to
focus on actually doing the tuning part."

And I completely agree. The alternative of having two separate sources
of metadata is a very bad solution IMHO, as changes done to the
postgresql.conf file directly would completely break the tool used
otherwise. And parsing the actual postgresql.conf is simply not enough.
First because it's difficult to parse all the comments correctly. Then,
because it lacks a lot of the information required for GUI tools and
auto-tunning tools.

I'm sure you have read the GUCS Overhaul wiki page [2], that already
points out many ideas related to this one.

>
> But if we make this change, existing users will be inconvenienced,

And I somehow agree. Adding some metainformation to the postgresql.conf
file may be *a little* bit inconvenient for some users. But those users
are probably pgsql-hackers or advanced DBAs. And I'm sure everybody
here knows keyboard shortcuts and how to fiddle with larger, yet
structured, files. We all know how to grep and sed and awk this files,
right?

On the other hand, this metainformation would be extremely useful for
newbies, not-that-unexperienced DBAs and even users which go to other
databases because postgres is hard to configure. Adding it would be
extremely valuable for them because:

- they would have much more inlined information about the parameter, and
- they could use tools to help them with the configuration

So the question is: which group of users are we trying to please? And
even if the answer would be the pgsql-hackers and not the rest of the
world out there, is that much of an inconvenience what I'm saying, to
deny the rest of advantages that it may bring?

Thanks for your comments,

aht

[1]
http://www.postgresql.org/message-id/Pine.GSO.4.64.0806020452220.26912@westnet.com
[2] http://wiki.postgresql.org/wiki/GUCS_Overhaul

--
Álvaro Hernández Tortosa

-----------
NOSYS
Networked Open SYStems