Re: Random PGDLLIMPORTing

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Random PGDLLIMPORTing
Дата
Msg-id CAMsr+YHpi_6bFGaCwuO--EzM73JaoWznjFDeVDYLY6gYZkoxVA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Random PGDLLIMPORTing  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Random PGDLLIMPORTing
Список pgsql-hackers
On 25 November 2016 at 07:36, Michael Paquier <michael.paquier@gmail.com> wrote:
> On Thu, Nov 24, 2016 at 11:01 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Thu, Nov 24, 2016 at 2:58 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> My guess is that PGDLLIMPORT has been added explicitly when somebody needed
>> it for something, without any actual thought. I can't say I see any reason
>> not to export the other ones as well -- more that maybe there are even more
>> that are needed?
>
> Yes, more or less. The reasoning behind at least the PostmasterPID bit is that:
> https://www.postgresql.org/message-id/CAB7nPqS_=14KRCDcH6NyRsW8c58J1cwXv6QCVS7YP-6tTHQ1nA@mail.gmail.com
> That resulted in cac83219.
>
> The other ones could perhaps be marked with PGDLLIMPORT. Now usually
> we need a use-case behind this change, and there are not that many
> hackers on Windows doing much plugin development.

Exactly, that's why nobody's been shouting yet.

The use case is is exactly the same as the use case for these vars
existing. IsBackgroundWorker in particular makes no sense to have at
all if it isn't exported, and the only reason nobody's complaining is
that nobody's building cassert binaries under Windows or has tried to
write anything that has behaviour that cares if it's in a bgworker or
not.

PGDLLIMPORT is free, so the question should be "is there a reason not
to add it here?".

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: patch: function xmltable
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Declarative partitioning - another take