Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CAOBaU_Zfe9BU84gtxFp70Y_w-L94XC+9ex9OjS-9G-pd4iR2=g@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Craig Ringer <craig.ringer@enterprisedb.com>)
List pgsql-hackers
On Mon, Aug 23, 2021 at 10:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Bruce Momjian <bruce@momjian.us> writes:
> > On Mon, Aug 23, 2021 at 10:15:04AM -0400, Tom Lane wrote:
> >> By that argument, *every* globally-visible variable should be marked
> >> PGDLLIMPORT.  But the mere fact that two backend .c files need to access
>
> > No, Julien says 99% need only the GUCs, so that is not the argument I am
> > making.
>
> That's a claim unbacked by any evidence that I've seen.  More to
> the point, we already have a mechanism that extensions can/should
> use to read and write GUC settings, and it's not direct access.

I clearly didn't try all single extension available out there.  It's
excessively annoying to compile extensions on Windows, and also I
don't have a lot of dependencies installed so there are some that I
wasn't able to test since I'm lacking some other lib and given my
absolute lack of knowledge of that platform I didn't spent time trying
to install those.

I think I tested a dozen of "small" extensions (I'm assuming that the
big one like postgis would require too much effort to build, and they
probably already take care of Windows compatibility), and I only faced
this problem.  That's maybe not a representative set, but I also doubt
that I was unlucky enough to find the few only exceptions.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Julien Rouhaud
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT