Re: Mark all GUC variable as PGDLLIMPORT

On Tue, Aug 24, 2021 at 4:28 AM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)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