On 08/23/21 14:30, Robert Haas wrote: > it seems likely that this proposed > API would have the exact same problem, because it would let people do > exactly the same thing. And, going through this proposed API would > still be significantly more expensive than just accessing the bare > variables, because you'd at least have to do some kind of lookup based > on the GUC name
I think the API ideas in [0] would not let people do exactly the same thing.
They would avoid exposing the bare variables to overwrite. Not that there has been any plague of extensions going and overwriting GUCs, but I think in some messages on this thread I detected a sense that in principle it's better if an API precludes it, and that makes sense to me.
The second idea also avoids the expense of name-based lookup (except once at extension initialization), and in fact minimizes the cost of obtaining the current value when needed, by slightly increasing the infrequent cost of updating values.
I'd be generally in favour of something that reduced our reliance on the current chaotic and inconsistent jumble of globals which are a semi-random combination of compilation-unit-scoped, globally-scoped-except-on-Windows and globally scoped.
Tackling GUCs would be a good start. Especially given the number of GUCs where the actual GUC value isn't the state that anyone should be interacting with directly since a hook maintains the "real" state derived from the GUC storage.
And preventing direct writes to GUCs seems like a clearly correct thing to do.
Some consideration of performance would be important for some of the hotter GUCs, of course, but most extensions won't be hammering most GUC access a lot.