On 18.11.25 23:39, David Rowley wrote:
On Tue, 18 Nov 2025 at 21:50, Peter Eisentraut <[email protected]> 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.
