Re: Should contrib modules install .h files? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Should contrib modules install .h files?
Date
Msg-id CAMsr+YGTiO7E+WSeVPzBHJVpA_Jyf6dGR+33DRRiKvVFbsynSQ@mail.gmail.com
Whole thread Raw
In response to Should contrib modules install .h files?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Should contrib modules install .h files?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On 2 July 2018 at 02:23, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
So I have this immediate problem: a PGXS build of a module, specifically
an hstore transform for a non-core PL, is much harder than it should be
because it has no way to get at hstore.h since that file is never
installed anywhere.

Should that be changed?


I think there's agreement in the thread that it should, and strong +1 from me.

I just wanted to pipe up with something Petr pointed out during pglogical development, which is that Pg offers a handy tool to help extensions link up with each other - find_rendezvous_variable(...) from dfmgr.c / fmgr.h . 

It's a real shame it's not more visible in contrib/ examples and the docs. Any suggestions on where it should appear in the docs? Somewhere in extend.sgml, presumably.

You still need a header from the other extension to *use* it, but it provides a massively easier way to find a struct of API function pointers. Prior to using it, I had a hack where I dlopen()ed the other shared library directly, and I'd also trialled using the fmgr to call a 'returns internal' function to get the API pointers struct that way.

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

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Clarify use of temporary tables within partition trees