Re: Create function prototype as part of PG_FUNCTION_INFO_V1
От | Craig Ringer |
---|---|
Тема | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
Дата | |
Msg-id | 534E25A8.20309@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 04/15/2014 10:17 PM, Tom Lane wrote: >> > 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? Good idea. Personally, I don't care about Windows enough. I want it to work, but performance optimisation is beyond what I'm bothered with. Another useful test would be to modify libpq as described above, so its headers set __declspec(dllexport) on its exports during compilation and its headers set __declspec(dllimport) when included while compiling other binaries that will link to libpq. Then use *that* in pgbench too and see if it makes any meaningful difference. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: