From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Flanagan" <kevin-f(at)linkprior(dot)com> |
Cc: | "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Access violation from palloc, Visual Studio 2005, C-language function |
Date: | 2010-03-10 22:42:51 |
Message-ID: | 21691.1268260971@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Flanagan" <kevin-f(at)linkprior(dot)com> writes:
> Aha. I'd read that the build process for the contrib modules involved
> generating a .DEF file for the necessary exports. I had the impression that
> defining BUILDING_DLL was an alternative, addressing (part) of the issue
> (that is, PG_FUNCTION_INFO_V1 declares functions as 'extern PGDLLIMPORT',
> and if you define BUILDING_DLL, then PGDLLIMPORT is defined as ' __declspec
> (dllexport)'). But you're quite right, if I take out the BUILDING_DLL
> definition, and put the __declspec (dllexport) stuff in piecemeal, the
> access violation goes away. Thank goodness.
I remember having complained that that part of the PG_FUNCTION_INFO_V1
macro seemed backwards, and never really getting a satisfactory
explanation of why it isn't (ie, why it shouldn't be designed to expand
as __declspec (dllexport) instead). But anyway, I think the
conventional wisdom for exporting functions from a loadable module is
to use "dlltool --export-all" rather than bothering with being
selective.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-03-10 22:45:25 | Re: PD_ALL_VISIBLE flag error on 9.0 alpha 4 |
Previous Message | Heikki Linnakangas | 2010-03-10 21:08:44 | Re: PD_ALL_VISIBLE flag error on 9.0 alpha 4 |