Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Date
Msg-id CAMsr+YGU==-zKN60PUdOm_FL8g+AVLj_z88sqPuey_cS9t0oPA@mail.gmail.com
Whole thread Raw
In response to Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 18 October 2016 at 04:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> As for the core problem, I wonder why we aren't recommending that
> third-party modules be built using the same infrastructure contrib
> uses, rather than people ginning up their own infrastructure and
> then finding out the hard way that that means they need PGDLLEXPORT
> marks.

Effectively, "PGXS for Windows".

I had a quick look at getting that going a while ago, but it was going
to leave me eyeballs-deep in Perl and I quickly found something more
interesting to do.

I think it's worthwhile, but only if we can agree in advance that the
necessary infrastructure will be backported to all supported branches
if at all viable. Otherwise it's a massive waste of time, since you
can't actually avoid needing your own homebrew build for 5+ years.

I've kind of been hoping the CMake work would make the whole mess of
Perl build stuff go away. CMake would solve this quite neatly since we
can bundle CMake parameters file for inclusion in other projects and
could also tell pg_config how to point to it. Extensions then become
trivial CMake projects.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Next
From: Craig Ringer
Date:
Subject: Re: Idempotency for all DDL statements