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 10624.1476735097@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Robert Haas <robertmhaas@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Next
From: Robert Haas
Date:
Subject: Re: Parallel bitmap heap scan