Craig Ringer <craig@2ndquadrant.com> writes:
> Turned out to be trivial to test. If the prototype with PGDLLEXPORT
> appears *first*, then all is well. If the prototype with PGDLLEXPORT
> appears AFTER a user-provided prototype it fails with:
That's sort of what I thought would happen. It's problematic because
putting the extern before the PG_FUNCTION_INFO_V1 is standard practice,
especially if you have the extern in a header file.
> I think we can just emit a prototype for the function from
> PG_FUNCTION_INFO_V1.
Doesn't sound like it; we'll still be forced to modify or remove
manually-written externs in basically all contrib and third-party code,
if we want it to build on Windows. Which, as I said before, does not
seem to me to be a workable solution path at all. It would take
years to track down all the third-party code and get it fixed, if
the authors don't themselves build/test on Windows.
And I continue to maintain that it's not acceptable for the Windows port
to require this anyway. If any other platform came to us and said "hey
guys, you need to plaster this non-ANSI-C decoration on every exported
function", what response do you think they'd get?
One last point is that "automatically export every external symbol" is
exactly what happens for these modules on Unix-ish platforms. If it
doesn't work the same way on Windows, we're just opening ourselves up to
subtle portability issues.
This needs to be fixed in the Windows build system, not the source code.
regards, tom lane
