From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Overhauling GUCS |
Date: | 2008-06-05 00:26:14 |
Message-ID: | 7509.1212625574@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith <gsmith(at)gregsmith(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-06-05 00:30:34 | Re: Core team statement on replication in PostgreSQL |
Previous Message | Tom Lane | 2008-06-05 00:23:17 | Re: Overhauling GUCS |