Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
Искать
От
Julien Rouhaud
Тема
Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id
20210822122551.f2xyy6vck6efjyee@nol
Ответ на
Список
Дерево обсуждения
Mark all GUC variable as PGDLLIMPORT Julien Rouhaud <rjuju123@gmail.com>
Re: Mark all GUC variable as PGDLLIMPORT Michael Paquier <michael@paquier.xyz>
Re: Mark all GUC variable as PGDLLIMPORT Julien Rouhaud <rjuju123@gmail.com>
Re: Mark all GUC variable as PGDLLIMPORT Tom Lane <tgl@sss.pgh.pa.us>
Re: Mark all GUC variable as PGDLLIMPORT Pavel Stehule <pavel.stehule@gmail.com>
Re: Mark all GUC variable as PGDLLIMPORT Julien Rouhaud <rjuju123@gmail.com>
On Sun, Aug 22, 2021 at 02:17:16PM +0200, Pavel Stehule wrote:
> 
> Is true, so it increases differences between Windows and Unix, and fixing
> these issues is not fun work. On the other hand, maybe direct access to
> these variables from extensions is an antipattern, and we should use a
> direct function call API and functions current_setting and set_config. The
> overhead is usually not too big.

Yes, and that's what I did for one of my extensions.  But that's still a bit of
overhead, and extra burden only seen when trying to have Windows compatiblity,
and I hope I can get rid of that at some point.

If direct variable access shouldn't be possible, then we should explicitly tag
those with __attribute__ ((visibility ("hidden"))) or something like that to
have a more consistent behavior.


В списке pgsql-hackers по дате отправления
От: Pavel Stehule
Дата:
От: Thomas Munro
Дата:
Сообщение: Spelling change in LLVM 14 API
FAQ