Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id CA+Tgmoa=936bFBvUy=CXumyS0Tv9RLFtesQOVX9Ep=y=Sn=L5Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Mark all GUC variable as PGDLLIMPORT  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: Mark all GUC variable as PGDLLIMPORT  (Chapman Flack <chap@anastigmatix.net>)
Re: Mark all GUC variable as PGDLLIMPORT  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, Aug 24, 2021 at 3:36 PM Chapman Flack <chap@anastigmatix.net> wrote:
> Peter may have advocated for that kind of across-the-board adoption;
> my leaning is more to add an API that /can/ be adopted, initially with
> separately-linked extensions as the audience. Nothing would stop it being
> used in core as well, but no reason to change any site where it did not
> offer an advantage.
>
> I generally tend to be an incrementalist.

Sure, me too, but the point for me is that there doesn't seem to be a
shred of a reason to go this way at all. We've turned a discussion
about adding PGDLLIMPORT, which ought to be totally uncontroversial,
into some kind of a discussion about adding an API layer that no one
wants to prevent a hypothetical failure mode not in evidence.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [PATCH] Disable bgworkers during servers start in pg_upgrade
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT