Re: Mark all GUC variable as PGDLLIMPORT

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> On 02/13/22 15:16, Tom Lane wrote:
>> Why not just provide equivalents to GetConfigOption() that can
>> deliver int, float8, etc values instead of strings?

> And repeat the bsearch to find the option every time the interested
> extension wants to check the value, even when what it learns is that
> the value has not changed? And make it the job of every piece of
> interested extension code to save the last-retrieved value and compare
> if it wants to detect that it's changed? When the GUC machinery already
> has code that executes exactly when a value is being supplied for
> an option?

(shrug) You could argue the performance aspect either way. If the
core GUC code updates a value 1000 times while the extension consults
the result once, you've probably lost money on the deal.

As for the bsearch, we could improve on that when and if it's shown
to be a bottleneck --- converting to a hash table ought to pretty
much fix any worries there. Or we could provide APIs that let an
extension look up a "struct config_generic *" once and then fetch
directly using that pointer. (But I'd prefer not to, since it'd
constrain the internals more than I think is wise.)

regards, tom lane