On Wed, 30 Jun 2021 at 04:49, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
George Tarasov <george.v.tarasov@xxxxxxxxx> 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?
