Re: Random PGDLLIMPORTing - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Random PGDLLIMPORTing
Date
Msg-id CAMsr+YHpi_6bFGaCwuO--EzM73JaoWznjFDeVDYLY6gYZkoxVA@mail.gmail.com
Whole thread Raw
In response to Re: Random PGDLLIMPORTing  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Random PGDLLIMPORTing  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: patch: function xmltable
Next
From: Amit Langote
Date:
Subject: Re: Declarative partitioning - another take