Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 2307C2E014E for ; Wed, 4 Jun 2008 21:47:16 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 25551-02-9 for ; Wed, 4 Jun 2008 21:47:00 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 6347E2E00E4 for ; Wed, 4 Jun 2008 21:26:17 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m550QE6P007510; Wed, 4 Jun 2008 20:26:14 -0400 (EDT) To: Greg Smith cc: pgsql-hackers@postgresql.org, Josh Berkus Subject: Re: Overhauling GUCS In-reply-to: References: <48409D1E.3070208@agliodbs.com> <200806010032.53337.peter_e@gmx.net> <17932.1212415926@sss.pgh.pa.us> <20080604131810.GH65238@decibel.org> <4846A483.8000001@pse-consulting.de> <29525.1212613052@sss.pgh.pa.us> Comments: In-reply-to Greg Smith message dated "Wed, 04 Jun 2008 20:16:55 -0400" Date: Wed, 04 Jun 2008 20:26:14 -0400 Message-ID: <7509.1212625574@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/200 X-Sequence-Number: 119313 Greg Smith writes: > On Wed, 4 Jun 2008, Tom Lane wrote: >> The real problem we need to solve is how to allow newbies to have the >> system auto-configured to something that more or less solves their >> problems. Putting the config settings in XML does not accomplish that, >> and neither does putting them inside the database. > The subtle issue here is that what makes sense for the database > configuration changes over time; there's not just one initial generation > and you're done. postgresql.conf files can end up moving from one machine > to another for example. I think something that doesn't recognize that > reality and move toward a "tune-up" capability as well as initial > generation wouldn't be as useful, As I just mentioned to someone else, I don't see any point in framing it as an "initial generation" problem at all. initdb will already give you settings that work, for some value of "work". The config wizard really only needs to deal with the case of tuning an existing installation. > and that's where putting the settings > inside the database helps so much. How does it help, pray tell? If you mean being able to see what the existing settings are, pg_settings already does that. regards, tom lane