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.
