On Wed, Oct 28, 2009 at 12:08 PM, Josh Berkus <j...@agliodbs.com> wrote: >> Perhaps the ease of writing something like that with sed or perl has >> caused me to underestimate the effort required in C. I am curious >> whether you actually mean that, or said it for rhetorical effect. > > I actually mean that. It *looks* easy in perl, and in fact *is* easy > for *your* postgresql.conf which you control. But writing a parser for > every postgresql.conf which exists in the world, no matter how someone > has hacked it up creatively? No matter how they've handled upgrades? > For every version of PostgreSQL? That requires writing a full parser > with grammar and near-turing capabilities.
I think we're getting distracted by the basic parsing questions. These are actually solvable -- pgadmin solves them today even. I think the bigger problem is the semantic questions. If I've lowered random_page_cost and your tool decides it should raise sequential_page_cost should it raise random_page_cost proportionally from my setting or to the absolute value it calculates? When it does will I be annoyed to see my settings overwritten? What if I set some of the cpu_* parameters based on my random_page_cost setting and now that you've overwritten my random_page_cost setting they're all out of whack? And not all programs editing these files will be equally intelligent. Say I post a snippet of configuration and say to drop it in wholesale into your postgresql.conf.d. Then the user runs autotune which drops a configuration in after it which overrides those settings. Then later I post an updated snippet and the user replaces the original snippet. If they're in separate files and he put the snippet in before the autotune configuration then he doesn't have to worry if the new snippet contains things which autotune overrode. They'll still override the new settings. If you keep them separate then the actual settings may not be in sync but at least I can see each group of settings and understand what they were trying to do. The precedence remains the same. It also means the database could give warnings if files are overriding earlier files if we want that. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
