On 02/13/22 15:16, Tom Lane wrote: > That seems like about 10X more complexity than is warranted, > not only in terms of the infrastructure required, but also in > the intellectual complexity around "just when could that value > change?" > > 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? Clearly I'm not thinking here of the GUCs that are read-only views of values that are determined some other way. How many of those are there that are mutable, and could have their values changed without going through the GUC mechanisms? Also, I think there are some options that are only represented by an int, float8, etc., when shown, but whose native internal form is something else, like a struct. I was definitely contemplating that you could 'subscribe' to one of those too, by passing the address of an appropriate struct. But of course a GetConfigOption() flavor could work that way too. Regards, -Chap