Alvaro Herrera <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
