Re: Mark all GUC variable as PGDLLIMPORT

On Tue, 24 Aug 2021 at 02:31, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Aug 23, 2021 at 11:40 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> > In that case, why not improve the API with functions that return the
> > values in some native datatype? For scalars with native C types (int,
> > floats, Boolean etc) this is easy enough; I bet it'll solve 99% of the
> > problems or more.
>
> Sure, but ... why bother?
>
> The entire argument rests on the presumption that there is some harm
> being done by people accessing the values directly, but I don't think
> that's true. And, if it were true, 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 to find the corresponding variable. It's just a
> solution in search of a problem.
>
> Nothing bad happens when people write extensions that access GUC
> variables directly. It works totally, completely fine. Except on
> Windows.
>

Not only that, but postgres already exports every non-static function
symbol on both *nix and Windows, and every data symbol on *nix. A lot of
those function symbols are very internal and give anything that can call
them the ability to wreck absolute havoc on the server's state.

There is not even the thinnest pretense of Pg having a dedicated extension
API or any sort of internal vs public API separation. This ongoing pain
with PGDLLIMPORT on Windows is hard to see as anything but an excuse to
make working with and supporting Windows harder because some of us don't
like it. I happen to rather dislike working with Windows myself, but I get
to do it anyway, and I'd be very happy to remove this particular source of
pain.