Revert addition of PGDLLEXPORT in PG_FUNCTION_INFO_V1 macro.

This turns out not to be as harmless as I thought: MSVC will complain
if it sees an "extern" declaration without PGDLLEXPORT and then one with.
(Seems fairly silly, given that this can be changed after the fact by the
linker, but there you have it.)  Therefore, contrib modules that have
extern's for V1 functions in header files are falling over in the
buildfarm, since none of those externs are marked PGDLLEXPORT.

We might or might not conclude that we're willing to plaster those
declarations with PGDLLEXPORT in HEAD, but in any case there's no way we're
going to ship this change in the back branches.  Third-party authors would
not thank us for breaking their code in a minor release.  Hence, revert
the addition of PGDLLEXPORT (but let's keep the extra info in the comment).
If we do the other changes we can revert this commit in HEAD.

Per buildfarm.
This commit is contained in:
Tom Lane 2016-10-12 18:01:43 -04:00
parent c0a3b211bc
commit 4f52fd3c6d
1 changed files with 4 additions and 3 deletions

View File

@ -350,11 +350,12 @@ typedef const Pg_finfo_record *(*PGFInfoFunction) (void);
*
* On Windows, the function and info function must be exported. Our normal
* build processes take care of that via .DEF files or --export-all-symbols.
* We add PGDLLEXPORT nonetheless so that C functions built with a
* different build process are guaranteed to be exported.
* Module authors using a different build process might need to manually
* declare the function PGDLLEXPORT. We do that automatically here for the
* info function, since authors shouldn't need to be explicitly aware of it.
*/
#define PG_FUNCTION_INFO_V1(funcname) \
extern PGDLLEXPORT Datum funcname(PG_FUNCTION_ARGS); \
extern Datum funcname(PG_FUNCTION_ARGS); \
extern PGDLLEXPORT const Pg_finfo_record * CppConcat(pg_finfo_,funcname)(void); \
const Pg_finfo_record * \
CppConcat(pg_finfo_,funcname) (void) \