Craig Ringer <craig@2ndquadrant.com> writes:
> On 04/15/2014 03:39 AM, Tom Lane wrote:
>> I still wish we could get rid of this problem by fixing the Windows build
>> recipes so that the PGDLLEXPORT marking wasn't needed. We proved to
>> ourselves recently that getting rid of PGDLLIMPORT on global variables
>> wouldn't work, but I'm not sure that the function end of it was really
>> investigated.
> My understanding is that we *can* drop PGDLLEXPORT on functions without
> actively breaking anything. But we probably shouldn't.
> If we omit PGDLLEXPORT, the linker of the DLL/executable that imports
> the extern function will generate a thunk from the .LIB file for the
> target DLL during linkage; this thunk within the DLL/EXE with the
> undefined extern then jumps to the real address within the defining DLL/EXE.
TBH, if the only argument for this is a small efficiency difference,
then to my mind it barely requires discussion. I don't give one hoot
about micro-optimization for the Windows platform; I'm satisfied if
it works at all there. And I seriously doubt that a couple more cycles to
call any function implemented in a loadable module would matter anyway.
> I actually think we should *add* a LIBPQEXPORT that handles this for
> libpq, much like PGDLLEXPORT does for postgres(.exe). And in the
> process, rename PGDLLEXPORT to POSTGRESEXPORT or PGSERVEREXPORT or
> something.
My reaction to that is "not bloody likely". I remarked on this upthread
already, but there is absolutely no way that I want to clutter our source
code with platform-specific markings like that.
Perhaps somebody could try a Windows build with PGDLLEXPORT defined to
empty, and verify that it works, and if so do a pgbench comparison
against a build done the existing way?
regards, tom lane