On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
I wouldn't think that cross-file references would be especially
common. Functions that take PG_FUNCTION_ARGS and return Datum aren't
a lot of fun to call from C. But maybe I'm wrong.
> 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.
So, they'd need to generate export files somehow?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
