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: http://www.postgresql.org/mailpref/pgsql-hackers
