Re: RFC: programmable file format for postgresql.conf - Mailing list pgsql-hackers

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