Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Дата
Msg-id 1817.1476307651@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Vitaly Burovoy
Дата:
Сообщение: Re: macaddr 64 bit (EUI-64) datatype support
Следующее
От: Artur Zakirov
Дата:
Сообщение: Re: FTS Configuration option