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

From Craig Ringer
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CAGRY4nyPaxsgeOgP5s0R1Jo7Px8=UCRT_Mw-DAGVqkMsnyxAfw@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Wed, 25 Aug 2021 at 22:36, Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Aug 25, 2021 at 4:06 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Aug 24, 2021 at 5:06 PM Chapman Flack <chap@anastigmatix.net> wrote:
> > The thing is, I think I have somewhere a list of all the threads on this
> > topic that I've read through since the first time I had to come with my own
> > hat in hand asking for a PGDLLIMPORT on something, years ago now, and
> > I don't think I have ever seen one where it was as uncontroversial
> > as you suggest.
>
> It does tend to be controversial, but I think that's basically only
> because Tom Lane has reservations about it. I think if Tom dropped his
> opposition to this, nobody else would really care. And I think that
> would be a good thing for the project.


I have only one consideration about it, and that's a technical one :)

Does this in some way have an effect on the size of the binary and/or
the time it takes to load it?

On *nix, no.

On Windows, very, very minimally.

We *should* be looking into making  private symbols we can't make non-static have hidden visibility at link time, i.e. be DSO-private.  This can have a huge impact on link-time optimisation and inlining.

But doing so is quite orthogonal to the matter of fixing a linkage issue on Windows. By making select symbols hidden we'd be *reducing* the exposed set of functions and data symbols in a disciplined and progressive way on all platforms. Useful but different.

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Craig Ringer
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT