Re: Should contrib modules install .h files?

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> I'm thinking that $(includedir_server)/$(MODULEDIR) would be a
> reasonable place? MODULEDIR defaults to either "contrib" or "extension"
> depending on whether EXTENSION is set.
> Something like the attached patch seem reasonable?

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. There are already some that
are pretty shaky from this standpoint:

contrib$ ls */*.h
bloom/bloom.h pg_trgm/trgm.h
btree_gist/btree_gist.h pgcrypto/blf.h
btree_gist/btree_utils_num.h pgcrypto/imath.h
btree_gist/btree_utils_var.h pgcrypto/mbuf.h
cube/cubedata.h pgcrypto/md5.h
hstore/hstore.h pgcrypto/pgcrypto.h
intarray/_int.h pgcrypto/pgp.h
isn/EAN13.h pgcrypto/px-crypt.h
isn/ISBN.h pgcrypto/px.h
isn/ISMN.h pgcrypto/rijndael.h
isn/ISSN.h pgcrypto/sha1.h
isn/UPC.h postgres_fdw/postgres_fdw.h
isn/isn.h seg/segdata.h
ltree/crc32.h sepgsql/sepgsql.h
ltree/ltree.h tablefunc/tablefunc.h
pageinspect/pageinspect.h

Not sure about whether the MODULEDIR part is useful. Seems like
making a distinction between extensions and other contrib is
likely to create more headaches than it avoids.

BTW, it's somewhat interesting to think about whether we ought to
change the coding conventions so that extensions refer to their
own headers with a subdirectory, e.g., #include "bloom/bloom.h".
Having done that, all of contrib could build with a single
centrally-provided -I switch pointing at BUILDDIR/contrib/,
and there would be a path to allowing the code to build out of
tree by pointing that common -I at $(includedir_server)/ or
$(includedir_server)/MODULEDIR. This seems like it could be
a lot less messy as we accrete more cross-module references.

regards, tom lane