George Tarasov <george.v.tarasov@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?
