Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane wrote:
> > Hmm, I didn't recheck after Greg's patch, but in mine, it doesn't,
> > because the location is saved as "reset location" and restored when the
> > variable is reset. It worked fine in all cases I tested.
> Hmm. Actually, why is there a need to save and restore at all? There
> can certainly never be more than one recorded config-file location per
> variable. What about saying that each variable has one and only one
> filename/linenumber, but whether these are relevant to the current value
> is determined by whether the current value's source is S_FILE?
Hmm, this does make the patch a lot simpler. Attached. (Magnus was
visionary enough to put the correct test in the pg_settings definition.)
I also dropped the change to set_config_option, and added a new routine
to set the source file/line, as you suggested elsewhere. The only
problem is that we now have two bsearch calls for each option set in a
config file ... I don't want to change set_config_option just to be
able to return the struct config_generic for this routine's sake ...
Better ideas? Is this OK as is?
I noticed some weird things when the config files contain errors, but I
think it's outside this patch's scope.
(I dropped the "default" stuff for now, as it doesn't seem that a
consensus has been reached on that topic.)
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
In response to
pgsql-hackers by date
|Next:||From: Ron Mayer||Date: 2008-09-09 04:12:03|
|Subject: Re: [PATCH] Cleanup of GUC units code|
|Previous:||From: Stephen Frost||Date: 2008-09-09 02:35:33|
|Subject: [Patch Review] Copy column storage parameters on CREATE TABLELIKE/INHERITS|