Re: Mark all GUC variable as PGDLLIMPORT

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Date: 2021-08-25 15:00:12
Message-ID: CABUevEzHx4OHxdF+SJrF7+cvef4fUfwt03-nJVhxAE5gSy548Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 25, 2021 at 4:41 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Wed, Aug 25, 2021 at 4:06 PM Robert Haas <robertmhaas(at)gmail(dot)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?)

It should have no effect on local code.

PGDLLIMPORT turns into "__declspec (dllexport)" when building the
backend, which should have no effect on imports

(it turns into __declspec (dllimport) when building a frontend only,
but that's why we need it in the headers, iirc)

The only overhead I've seen discussions about int he docs around that
is the overhead of exporting by name vs exporting by ordinal.

> 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.

Actually, ti's clearly been a while since I dug into this

AFAICT we *do* actually export all the data symbols as well? At least
in the MSVC build where we use gendef.pl? Specifically, see
a5eed4d770.

The thing we need the PGDLLIMPORT definition for is to *import* them
on the other end?

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Esteban Zimanyi 2021-08-25 15:01:32 Regression tests for MobilityDB: Continous shutdowns at a random step
Previous Message Tom Lane 2021-08-25 14:55:52 Re: Bug in error reporting for multi-line JSON