Re: Should contrib modules install .h files?

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Should contrib modules install .h files?
Date: 2018-07-03 07:29:55
Message-ID: 12ba9c72-504f-b911-f0ce-1dff2826fa5b@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Then they perhaps should be renamed. That seems like a much simpler
solution.

The use case being discussed here is installing a data type extension's
header so you can write a transform for it. The extension's name as
well as the data type's own name already have to be pretty much globally
unique if you want it to be useful. So it doesn't seem very difficult
to me to have the extension install a single header file with that same
name.

The other side of this is that the PLs have to install their header
files. Which the in-core PLs already do. Would we we want to move
their header files under a new per-extension directory scheme?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-07-03 08:27:07 Re: Copy function for logical replication slots
Previous Message Andres Freund 2018-07-03 07:06:45 Pluggable Storage - Andres's take