> 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
signature.asc
Description: This is a digitally signed message part.
