Re: Mark all GUC variable as PGDLLIMPORT

On Tue, 24 Aug 2021 at 13:21, Craig Ringer <craig.ringer@enterprisedb.com>
wrote:

>
> There is not even the thinnest pretense of Pg having a dedicated extension
> API or any sort of internal vs public API separation.
>

Oh, and if we do want such a separation, we'll need to introduce a MUCH
lower-pain-and-overhead way to get related patches in. Otherwise it'll take
decades to add any necessary function wrappers for currently exported data
symbols, add necessary hooks, wrap or hide internal symbols and state, etc.

But ... what is the actual goal and expected outcome of such a hypothetical
public/private API separation?

It won't help meaningfully with server maintenance: We already break
extensions freely in major releases, and sometimes even minor releases. We
don't make any stable API promise at all. So any argument that it would
make maintenance of the core server easier is weak at best.

It won't help protect server runtime stability: The server is written in C,
and makes heavy use of non-opaque / non-hidden types. Many of which would
not be practical to hide without enormous refactoring if at all. Writing
any sort of "safe" C API is very difficult even when the exposed
functionality is very narrow and well defined. Even then such an API can
only help prevent inadvertent mistakes, since C programs are free to grovel
around in memory. Look at the mess with EXPORT_SYMBOL_GPL in the kernel for
just how ugly that can get. So I don't think there's any realistic way to
claim that narrowing the exposed API surface would make it safer to load
and run extensions that the user has not separately checked and reviewed or
obtained from a trusted source with robust testing practices. Certainly it
offers no benefit at all against a bad actor.

It won't make it safer to use untrusted extensions.

What will it do? Not much, in the short term, except cripple existing
extensions or add a pile of questionably useful code annotations. The only
real benefits I see are some improvement in link-time optimization and
export symbol table size. Both of which are nice, but IMO not worth the
pain by themselves for a pure C program. In C++, with its enormous symbol
tables it's absolutely worth it. But not really for Pg.

To be clear, I actually love the idea of starting to define a solid public
API, with API, ABI and semantic promises and associated tests. But to say
it's a nontrivial amount of work is an enormous understatement. And unless
done by an existing committer who is trusted to largely define a
provisional API without bike-shedding and arguing the merits of every
single part of it, it's nearly impossible to do with the way Pg is
currently developed.

It's completely beyond me why it's OK to export all function symbols on
Windows, but not all data symbols. Or why it's OK to export all data
symbols on *nix, but not on Windows.