From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
Date: | 2014-04-15 14:17:57 |
Message-ID: | 27019.1397571477@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-04-15 14:22:17 | Re: Custom Scan APIs (Re: Custom Plan node) |
Previous Message | Craig Ringer | 2014-04-15 13:31:14 | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |