Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Date
Msg-id 1817.1476307651@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Craig Ringer <craig.ringer@2ndquadrant.com>)
List pgsql-hackers
I wrote:
> Albe Laurenz <laurenz.albe@wien.gv.at> writes:
>> Tom Lane wrote:
>>> I'm okay with adding PGDLLEXPORT to the extern, but we should update
>>> that comment to note that it's not necessary with any of our standard
>>> Windows build processes.  (For that matter, the comment fails to explain
>>> why this macro is providing an extern for the base function at all...)

>> Here is a patch for that, including an attempt to improve the comment.

> Pushed with some further twiddling of the comment.

Well, the buildfarm doesn't like that even a little bit.  It seems that
the MSVC compiler does not like seeing both "extern Datum foo(...)" and
"extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in
a .h file is failing.  There is also quite a bit of phase-of-the-moon
behavior in here, because in some cases some functions are raising errors
and others that look entirely the same are not.

We could plaster all those declarations with PGDLLEXPORT, but I'm rather
considerably tempted to go back to the way things were, instead.  I do
not like patches that end up with Microsoft-droppings everywhere.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Vitaly Burovoy
Date:
Subject: Re: macaddr 64 bit (EUI-64) datatype support
Next
From: Artur Zakirov
Date:
Subject: Re: FTS Configuration option