From: Stephen Frost <sfrost@snowman.net>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>
Subject: Re: Should contrib modules install .h files?
Date: Sun, 22 Jul 2018 21:42:08 -0400
Message-ID: <20180723014208.GE27724@tamriel.snowman.net> (raw)
In-Reply-To: <87k1q8kokq.fsf@news-spur.riddles.org.uk>
References: <87y3euomjh.fsf@news-spur.riddles.org.uk>
<ee05ea4c-3d5b-0ec6-8daa-3ec66f021076@2ndquadrant.com>
<87tvpinfr4.fsf@news-spur.riddles.org.uk>
<63444.1530537990@sss.pgh.pa.us>
<12ba9c72-504f-b911-f0ce-1dff2826fa5b@2ndquadrant.com>
<87k1q8kokq.fsf@news-spur.riddles.org.uk>
Greetings,
* Andrew Gierth (andrew@tao11.riddles.org.uk) wrote:
> >>>>> "Peter" == Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>
> > On 02.07.18 15:26, Tom Lane wrote:
> >> FWIW, I agree with Andres' thought that each contrib module should
> >> have its own subdirectory under $(includedir_server). Otherwise
> >> we're going to be faced with questions about whether .h files need
> >> to be renamed because they're not globally unique enough.
>
> Peter> Then they perhaps should be renamed. That seems like a much
> Peter> simpler solution.
>
> Personally I think that more -I options is less pain than having to
> rename things or deal with conflicts.
Yeah, I don't care for the idea that we should expect all extensions,
forever going forward, to provide one single .h file which has to be
unique and non-conflicting with all other extensions, ever.
When I think about the demands of extensions, I tend to consider PostGIS
the prime example and I certainly would understand if they wanted to
install multiple headers (they have some 72 .h files from what I'm
seeing...).
So, +1 from me for having a directory for each extension.
> Where exactly are you suggesting that they should be installed? Directly
> in $(installdir_server), or in $(installdir_server)/extension or
> equivalent?
I certainly wouldn't want extension headers being mixed in with server
headers. I haven't got any great ideas about contrib-vs-extension, but
I'm, at least, leaning towards 'extension' as being the best answer
here.
> Peter> The use case being discussed here is installing a data type
> Peter> extension's header so you can write a transform for it. The
> Peter> extension's name as well as the data type's own name already
> Peter> have to be pretty much globally unique if you want it to be
> Peter> useful. So it doesn't seem very difficult to me to have the
> Peter> extension install a single header file with that same name.
>
> That's assuming a single header file, which might be a bit more
> restrictive than absolutely necessary.
Agreed that having a single header file is overly and unnecessairly
restrictive.
> Peter> The other side of this is that the PLs have to install their
> Peter> header files. Which the in-core PLs already do. Would we we want
> Peter> to move their header files under a new per-extension directory
> Peter> scheme?
>
> The in-core PLs could reasonably be grandfathered in in their current
> locations, at least for now.
Grandfathering them seems fine to me, but I don't hold that position
very strongly.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, andrew@tao11.riddles.org.uk, peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us, andres@anarazel.de
Subject: Re: Should contrib modules install .h files?
In-Reply-To: <20180723014208.GE27724@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox