Re: Create function prototype as part of PG_FUNCTION_INFO_V1 - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Create function prototype as part of PG_FUNCTION_INFO_V1
Date
Msg-id 534E25A8.20309@2ndquadrant.com
Whole thread Raw
In response to Re: Create function prototype as part of PG_FUNCTION_INFO_V1  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [doc] EXPLAIN CREATE MATERIALIZED VIEW AS?
Next
From: Craig Ringer
Date:
Subject: BGWorkers, shared memory pointers, and postmaster restart