Re: [gsmith@gregsmith.com: Re: [patch] GUC source file and line number]

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> 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.

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?

(This would help to address one of the other things I find annoying
about the patch, which is the amount of storage it eats up for N copies
of what will always be the same filename in practice...)

> 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.

Yeah, could be.  Maybe set_config_option shouldn't be declared in guc.h?

>> 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"?

Like it better than "default value" ...
        regards, tom lane