On Mon, Oct 17, 2016 at 4:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz <laurenz.a...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to