Re: Add missing PGDLLIMPORT markings

Поиск
Список
Период
Сортировка
Искать
От
Andres Freund
Тема
Re: Add missing PGDLLIMPORT markings
Дата
Msg-id
968FFBF1-3CF4-4DE7-9D07-AE5CBB8FFE43@anarazel.de
Ответ на
Список
Дерево обсуждения
Add missing PGDLLIMPORT markings Peter Eisentraut <peter@eisentraut.org>
Re: Add missing PGDLLIMPORT markings Peter Eisentraut <peter@eisentraut.org>
Re: Add missing PGDLLIMPORT markings Daniel Gustafsson <daniel@yesql.se>
Re: Add missing PGDLLIMPORT markings Daniel Gustafsson <daniel@yesql.se>
Re: Add missing PGDLLIMPORT markings Jacob Champion <jacob.champion@enterprisedb.com>
Re: Add missing PGDLLIMPORT markings Andres Freund <andres@anarazel.de>
Re: Add missing PGDLLIMPORT markings Robert Haas <robertmhaas@gmail.com>
Re: Add missing PGDLLIMPORT markings Andres Freund <andres@anarazel.de>
Re: Add missing PGDLLIMPORT markings Robert Haas <robertmhaas@gmail.com>
Re: Add missing PGDLLIMPORT markings Tom Lane <tgl@sss.pgh.pa.us>
Hi, 

On April 9, 2025 12:58:23 PM EDT, Robert Haas  wrote:
>On Wed, Apr 9, 2025 at 11:28 AM Andres Freund  wrote:
>> FWIW, the AIO ones really don't make sense to make public - the only reason
>> for those variables to exists is so they can be put into an array of
>> callbacks. There's no way an extension could ever benefit from them.  But I
>> guess we don't really have a way to tell mark_pgdllimport.pl that.
>
>I'm not here to say that you're wrong, but this kind of argument is
>exactly why we didn't use to mark a bunch of things PGDLLIMPORT that,
>as it turned out, extension developers actually wanted to use.
>
>I don't think we should go back to the bad old days where we litigated
>every case of marking something PGDLLIMPORT or not unless we have an
>extremely good reason for so doing.

Yeah, that's why I guessed that we will have to just mark these.

Fwiw, just marking everything is far from free. We prevent optimizations the compiler could make otherwise. Except of course that we have implicitly always done so in the main binary on ELF platforms, so "PGDLLIMPORT everything" kind of just removed the portability hazard.

I think eventually we ought to change the default visibility in the main binary to hidden, just like we do for extensions. Then the windows/everything else behavior difference vanishes and we actually get the benefit of being more restrictive on common platforms.  I think we  still ought to default to exporting symbols in such a world, just not always do so.  We probably should just require all externs are either marked "server only" or "visible to extensions", never just a plain extern.

Greetings, 

Andres 


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


В списке pgsql-hackers по дате отправления
От: Tomas Vondra
Дата:
От: Nathan Bossart
Дата:
FAQ