Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Greg just sent me this patch, augmenting the one I sent to add source
> > file and line to GUC vars; Greg's patch adds a column with the default
> > value of each var.
>
> I haven't tested, but doesn't this lose the source-location information
> if a setting acquired from the config file is temporarily overridden via
> SET (consider SET LOCAL, or a SET in a rolled-back xact)? It'll go to
> NULL and not come back.
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.
> Since there is no possibility that any module outside GUC should ever
> supply a config file location, I don't think that changing the API for
> set_config_option is a good idea. Instead have ProcessConfigFile()
> call some internal function that's not used by anyone else, and let
> set_config_option assume that it's setting a non-file-sourced value.
> That'd reduce the footprint of the patch quite a bit.
Will look into it. FWIW I think most of the callers of
set_config_option are already abusing the API, because they should be
calling SetConfigOption instead. Maybe this needs some cleanup.
> Also, I think that a reasonable case could be made for exposing
> both boot_val and reset_val in the view --- if there is a use for one,
> there is likely to be a use for the other.
How about having two new columns "reset value" and "boot value"?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
