Re: Should contrib modules install .h files?
От | Pavel Stehule |
---|---|
Тема | Re: Should contrib modules install .h files? |
Дата | |
Msg-id | CAFj8pRBbsQ2Lbiwkk3qW1HRxfGLpK11iP5HcRa+MRmN1C3gGpw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should contrib modules install .h files? (Craig Ringer <craig@2ndquadrant.com>) |
Список | 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.--
В списке pgsql-hackers по дате отправления: