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

From Bruce Momjian
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id 20210826024858.GA22637@momjian.us
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 25, 2021 at 10:41:14AM -0400, Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Wed, Aug 25, 2021 at 4:06 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >> 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.
> 
> > But in particular, both on that argument, and on the general
> > maintenance argument, I have a very hard time seeing how exporting the
> > GUC variables would be any worse than exporting the many hundreds of
> > functions we already export.
> 
> My beef about it has nothing to do with binary-size concerns, although
> that is an interesting angle.  (I wonder whether marking a variable
> PGDLLIMPORT has any negative effect on the cost of accessing it from
> within the core code?)  Rather, I'm unhappy with spreading even more
> Microsoft-droppings all over our source.  If there were some way to
> just do this automatically for all global variables without any source
> changes, I'd be content with that.  That would *really* make the
> platforms more nearly equivalent.

OK, so the big question is how can we minimize the code impact of this
feature?  Can we add some kind of checking so we don't forget to mark
anything?  Can we automate this somehow?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Added schema level support for publication.
Next
From: Andy Fan
Date:
Subject: Re: Window Function "Run Conditions"