> Opinions all?
>
> * Give up on being able to use one extension's header from another
> entirely, except in the special case of in-tree builds
There are already a good number of use cases with only hstore and intarray,
I'm in favor of this feature.
> * Install install-enabled contrib headers into an include/contrib/
> that's always on the pgxs include path, so you can still just "#include
> hstore.h" . For in-tree builds, explicit add other modules' contrib dirs
> as Peter has done in the proposed plperl_hstore and plpython_hstore.
> (Use unqualified names).
I don't like the idea to share a flat directory with different header files,
filenames can overlap.
> * Install install-enabled contrib headers to
> include/contrib/[modulename]/ . Within the module, use the unqualified
> header name. When referring to it from outside the module, use #include
> "contrib/modulename/header.h". Add $(top_srcdir) to the include path
> when building extensions in-tree.
not either, see my other mail. we still #include hstore.h when we want, we
just add that the header so it is available for PGXS builds. Contrib Makefile
still need to -I$(includedir_contrib)/hstore. What's new is that the header is
installed, not that we don't have to set FLAGS.
> Personally, I'm all for just using the local path when building the
> module, and the qualified path elsewhere. It requires only a relatively
> simple change, and I don't think that using "hstore.h" within hstore,
> and "contrib/hstore/hstore.h" elsewhere is of great concern.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation