Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Date: 2016-10-17 20:11:37
Message-ID: 10624.1476735097@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Oct 14, 2016 at 10:14 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-17 20:12:17 Re: Parallel bitmap heap scan
Previous Message Robert Haas 2016-10-17 20:09:55 Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran