Date: Sun, 22 Jul 2018 21:42:08 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org,
	Andres Freund <andres@anarazel.de>
Subject: Re: Should contrib modules install .h files?
Message-ID: <20180723014208.GE27724@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Y0YAr1Yha2dTbrgJ"
Content-Disposition: inline
In-Reply-To: <87k1q8kokq.fsf@news-spur.riddles.org.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--Y0YAr1Yha2dTbrgJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Andrew Gierth (andrew@tao11.riddles.org.uk) wrote:
> >>>>> "Peter" =3D=3D Peter Eisentraut <peter.eisentraut@2ndquadrant.com> =
writes:
>=20
>  > 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.
>=20
>  Peter> Then they perhaps should be renamed. That seems like a much
>  Peter> simpler solution.
>=20
> 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.
>=20
> 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?
>=20
> 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

--Y0YAr1Yha2dTbrgJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJbVTJvAAoJEO1sijiDR2RVybQP/AwJ074A4av5reHauobVYNuR
GIcyhNxQNBasqW8+ZDMdhZFcaakDKEO6e7wyXXX3glZsfXv9+yZoLaSshNuZf7df
Pu5L25Jh5sHBeR5+tW7LFGfRnl7EoO28QtwVNj7xm+V0uXYZBmUGDFP5lkH8V01r
crAAFX/kH3In4jzvSdcJ7Dak9RjJnelifv6ScRRhlgnuZnqLJuIamP2ejSFVFJ8j
s9zwG7bBdcDyXYWrBOO4wbRS2FFlpbtyGNxvYmPC/v36/lUv5oFnPL/j2lbE+N5+
AfWOgxeCi/d54NCMNxil6WtjbrvN22aW8ezu4sPPzraGnFSf+9wEbYijrGbKRuVw
8PAKGgXxm0F+suBDc/giOt6+1U8ZeYiPnP+lIGEWblBN0c7Wkbr+CWfus9OUi1n1
a+mfUiYBYp40rZp4xW803EMHVQcW3jgwdssjrc/ETeS3KZjVGKGqHm9kfYOJ6S6M
Cj8/oQuLcwB5fYsVYoSxBDZKE6wVE2Aa9C+HvZA5vCGRU3K4iIfQ/QZFvjtq1vqX
wvxMaw2qP3XfcMq+Nsy/I+rHRC9j4VnubeHHkl/FRJDoeM2awikMS0QZFmkTMkPC
7Lt+fGuHy2KCdACm/JSj8qjSrShDzMpk3MRzDPOH8C387ZmKJcln0UfGIPovGaqx
5FJwaFDEFd8H5GEqILqm
=6fre
-----END PGP SIGNATURE-----

--Y0YAr1Yha2dTbrgJ--