From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |
Date: | 2016-10-18 03:52:27 |
Message-ID: | CAMsr+YGU==-zKN60PUdOm_FL8g+AVLj_z88sqPuey_cS9t0oPA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18 October 2016 at 04:11, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-10-18 03:59:39 | Re: Idempotency for all DDL statements |
Previous Message | Craig Ringer | 2016-10-18 03:48:28 | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |