Re: Mark all GUC variable as PGDLLIMPORT
От | Andres Freund |
---|---|
Тема | Re: Mark all GUC variable as PGDLLIMPORT |
Дата | |
Msg-id | 20220219000218.rmhshnd7mxlr7wbh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Mark all GUC variable as PGDLLIMPORT (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Mark all GUC variable as PGDLLIMPORT
|
Список | pgsql-hackers |
Hi, On 2022-02-15 08:06:58 -0800, Andres Freund wrote: > The more I think about it the more I'm convinced that if we want to do this, > we should do it for variables and functions. Btw, if we were to do this, we should just use -fvisibility=hidden everywhere and would see the same set of failures on unixoid systems as on windows. Of course only in in-core extensions, but it'd still be better than nothing. I proposed using -fvisibility=hidden in extensions: https://postgr.es/m/20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de Mostly because using explicit symbol exports makes it a lot easier to build extensions libraries on windows (with meson, but also everything built outside of postgres with msvc). But also because it makes function calls *inside* an extension have noticeably lower overhead. And it makes the set of symbols exported smaller. One problem I encountered was that it's actually kind of hard to set build flags only for extension libraries: https://postgr.es/m/20220111025328.iq5g6uck53j5qtin%40alap3.anarazel.de But if we added explicit exports to everything we export, we'd not need to restrict the use of -fvisibility=hidden to extension libraries anymore. Would get decent error messages on all platforms. Subsequently we could yield a bit of performance from critical paths by marking selected symbols as *not* exported. That'd make them a tad cheaper to call and allow the optimizer more leeway. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: