Tom Lane wrote:
>> Well, the buildfarm doesn't like that even a little bit. It seems that
>> the MSVC compiler does not like seeing both "extern Datum foo(...)" and
>> "extern PGDLLEXPORT Datum foo(...)", so anything that had an extern in
>> a .h file is failing. There is also quite a bit of phase-of-the-moon
>> behavior in here, because in some cases some functions are raising errors
>> and others that look entirely the same are not.
>
> I take back the latter comment --- I was comparing HEAD source code
> against errors reported on back branches, and at least some of the
> discrepancies are explained by additions/removals of separate "extern"
> declarations. But still, if we want to do this we're going to need to
> put PGDLLEXPORT in every V1 function extern declaration. We might be
> able to remove some of the externs as unnecessary instead, but any way
> you slice it it's going to be messy.
>
> For the moment I've reverted the change.
Sorry for having caused the inconvenience.
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?
Of course one would have to check first that the SQL functions don't try to
call each other, which would require extra forward declarations...
If you are willing to consider that, I'd be happy to prepare a patch.
But I'd understand if you think that this is too much code churn for too little
benefit, even if it could be considered a clean-up.
In that case, I'd argue that in the sample in doc/src/sgml/xfunc.sgml
the function definitions should be changed to read
PGDLLEXPORT Datum foo(PG_FUNCTION_ARGS)
instead of
Datum foo(PG_FUNCTION_ARGS)
because without that the sample fails if you try to build it with MSVC
like the stackoverflow question did.
I'd be happy to prepare a patch for that as well.
Yours,
Laurenz Albe