From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Should contrib modules install .h files? |
Date: | 2018-07-31 22:34:54 |
Message-ID: | 384d19e8-bea1-1188-2324-f23f82a30d17@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23/07/2018 18:32, Andrew Gierth wrote:
>>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> Tom> As I said before, I think that we should change the existing
> Tom> contrib modules to be coded likewise, all using a single -I switch
> Tom> that points at SRCDIR/contrib. That'd help give people the right
> Tom> coding model to follow.
>
> I don't see that playing nicely with PGXS?
I'm also not on board that my random third-party extension now has to
refer to its own header files as "subdirectory/headerfile.h". Which
will mess up existing extensions that have header files in their tree.
Or at least I'm not totally sure what the exact proposal and real-world
implications are, with regard to existing extensions with one or more
header files.
By all means, let's make it easier for large or small extensions to
manage their header files with PGXS. But let's separate what PGXS can
and should do from what the extension's own file layout is.
But I think there are some fundamentally incompatible goals here with
regard to how the final -I options are supposed to look.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-07-31 22:38:25 | Re: Should contrib modules install .h files? |
Previous Message | Tom Lane | 2018-07-31 22:29:34 | Re: pg_upgrade from 9.4 to 10.4 |