Re: GUC thread-safety approaches

On 18.11.25 23:39, David Rowley wrote:
> On Tue, 18 Nov 2025 at 21:50, Peter Eisentraut <peter@eisentraut.org> wrote:
>> where get_config_val_*() would be a thin wrapper around hash_search()
>> (a bit like the existing GetConfigOption() and find_option(), but
>> without all the error checking).
>>
>> Would that be too expensive?
> 
> Why couldn't in-core GUCs be fields in the Session struct and have a
> hash table for storage of custom GUCs, and allow core to access the
> fields directly? Extensions would need to go through a function which
> does the hash lookup.

Until now, we've made it so that in-core and custom GUCs behave exactly 
the same, once defined.  Breaking that apart would create additional 
complexity.  Also, as a general design principle in PostgreSQL, 
extensions should have access to the same things as in-core code, and 
in-core code should use the APIs provided to extensions.