Re: Should contrib modules install .h files?
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-03T06:04:23Z
Lists: pgsql-hackers
2018-07-03 6:43 GMT+02:00 Craig Ringer <craig@2ndquadrant.com>: > 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. > +1 similar issue is with plpgsql. The header files are exported by not generic way. Regards Pavel > 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 > >
Commits
-
Fix out-of-tree build for transform modules.
- f1ca5a654d5d 11.0 landed
- 60f6756f9225 12.0 landed
-
Provide for contrib and pgxs modules to install include files.
- df163230b92b 12.0 landed
- d06eebce5fa4 11.0 landed