On Wed, 30 Jun 2021 at 04:49, Tom Lane <t...@sss.pgh.pa.us> wrote:
> George Tarasov <george.v.tara...@gmail.com> writes:
> > So, my questions are there any rules / descriptions / agreements inside
> > the PostgreSQL Project that define which global variables inside a core
> > code should by specified by a PGDLLIMPORT and which should not?? Or
> > there is freedom; you need this variable in the extension (under
> > Windows), make patch for it yourself! Or there is plan in the community
> > that all global non-static variables should be PGDLLIMPORT-ed by default
> > in the future?? What the right way to propose the PGDLLIMPORT patch to
> > the master and back-ported PostgreSQL code in order to avoid dup patches
> > in the extensions?
>
> Our policy so far has been to add PGDLLIMPORT to variables for which
> someone makes a case that an extension would have a reasonable use
> for it. The bar's not terribly high, but it does exist. The idea of
> just doing a blanket s/extern/extern PGDLLIMPORT/g has been discussed
> and rejected, because we don't want to commit to supporting absolutely
> every global variable as something that's okay for extensions to touch.
>
I agree that it doesn't make sense to mark all of them as a blanket rule.
I'd like to explicitly tag *non*-exported externs as
__attribute__(("hidden")) on GCC-alike ELF systems to ensure that extension
authors don't rely on them then later find they cannot be used on Windows.
Obviously wrapped in some PG_NO_EXPORT or PG_DLL_HIDDEN macro.
I'm updating a patch at the moment that makes all GUC storage and most
variables computed from GUCs during hook execution PGDLLIMPORT. It might
make sense to follow that up with a patch to make non-export vars hidden.
But I vaguely recall raising this before and some folks not being a fan of
the extra noise on each line?
