On Tue, 24 Aug 2021 at 05:08, Chapman Flack <c...@anastigmatix.net> wrote:
> 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.
