On Wed, Aug 25, 2021 at 4:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Magnus Hagander <mag...@hagander.net> writes: > > On Wed, Aug 25, 2021 at 4:06 PM Robert Haas <robertmh...@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?)
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/
