Re: Should contrib modules install .h files?

Greetings,

* Andrew Gierth (andrew(at)tao11(dot)riddles(dot)org(dot)uk) wrote:
> >>>>> "Peter" == Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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