On Tue, Aug 24, 2021 at 4:28 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > If there were an API, then in-core code should use it as well.
...which is presumably never going to happen, because the performance cost would, I think, be quite terrible. If you really had to force everything through an API, I think what you'd want to do is define an API where code can look up a handle object for a GUC using the name of the GUC, and then hold onto a pointer to the handle and use that for future accesses, so that you don't have to keep incurring the expense of a hash table hit on every access. But even if you did that, preventing "unauthorized" writes to GUC variables would require a function call for every access. That function would be pretty trivial, but it would have to exist, and... > If, for example, an extension wanted to define a "float16" type, then it > should be able to access extra_float_digits in the *same way* as > float4out() and float8out() can access it. This is clearly not possible > today. ...if you used it for something like this, it would probably show up in the profile, and we would get demands to remove that API and allow direct access to the variables, which is all anybody is asking for here anyway, and which is what pretty much everyone, whether they develop for core or some extension, does and wants to do. This also brings me to another point, which is that I do not think there is anyone who actually wants an API like this. I believe that extension developers find it rather convenient that they can make use of all of the backend functions and variables that PostgreSQL exposes, and that a lot of them would be deeply unhappy if we removed that access. As an occasional extension maintainer myself, I know I would be. And, as Craig quite rightly points out upthread, we would not get anything in return for making those people unhappy. I don't know why we would even consider doing something that would benefit nobody, greatly inconvenience some people, and generally stifle innovation in the PostgreSQL ecosystem. Adding PGDLLIMPORT markings, on the other hand, would hurt nobody, be very convenient for some people, and encourage innovation in the PostgreSQL ecosystem. -- Robert Haas EDB: http://www.enterprisedb.com