Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Дата
Msg-id 10624.1476735097@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Robert Haas <robertmhaas@gmail.com>)
Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
>> Actually I would say that the correct solution is to remove the function
>> declarations from all the header files in contrib, since from commit e7128e8d
>> on the functions are declared by PG_FUNCTION_INFO_V1 anyway, right?

> Right.  Why isn't that already the case?  Commit e7128e8d seems to
> have tried.  Did it just miss a bunch of cases?

That only works to the extent that there are no cross-file references to
those symbols within the extension.  If that's true for 99% or more of
them then this is probably a good way to go.  If it's only true for, say,
75%, I'm not sure we want to decimate the headers that way.  We'd end
up with something doubly ugly: both haphazard-looking lists of only
some of the symbols, and PGDLLEXPORT marks on those that remain.

As for the core problem, I wonder why we aren't recommending that
third-party modules be built using the same infrastructure contrib
uses, rather than people ginning up their own infrastructure and
then finding out the hard way that that means they need PGDLLEXPORT
marks.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Parallel bitmap heap scan