Re: Should contrib modules install .h files?

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