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