| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| 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 14:55:39 |
| Message-ID: | 876.1476802539@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> 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".
Yeah.
> 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.
Agreed, it'd be wise not to put any effort into that until we see
whether the CMake conversion succeeds.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-10-18 14:58:04 | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |
| Previous Message | Andreas Joseph Krogh | 2016-10-18 14:51:54 | Re: Move pg_largeobject to a different tablespace *without* turning on system_table_mods. |