Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Tom> My impression is that there was consensus for per-extension
> Tom> subdirectories, but the usage scenario isn't totally designed yet.
> Tom> In principle, only the layout question has to be resolved to make
> Tom> it OK to ship this in v11.
> Currently, everything is agnostic about the usage scenario - the
> existing extension include files will work with either
> -I$(includedir_server)/extension and #include "hstore/hstore.h", or with
> -I$(includedir_server)/extension/hstore and #include "hstore.h".
Well, the point is we don't want agnosticism --- we want a clear
usage model for people to follow.
> Tom> On the other hand, if there's no very practical way to use the
> Tom> per-extension subdirectory layout,
> What constitutes "practical"?
Something that copes with selecting the right headers if you're rebuilding
a module whose headers are already installed (as you mentioned upthread).
Something that copes with different modules installing headers with the
same base name. Allowing for that was the driving force for going with
subdirectory-per-extension, but if we really want that to work, there
seems to be no alternative but for extensions to write qualified header
names (#include "hstore/hstore.h" not #include "hstore.h"). Andres,
for one, seemed to think that wouldn't play nicely with PGXS, though
I'm not sure why not. Maybe he only meant that an extension's *own*
headers shouldn't be referenced that way.
Maybe this all just works without much thought, but given that smart
people like Peter E. seem to be unsure of that, I'd sure like to see
a concrete set of rules that extensions should follow for this.
There's also a question of whether we need to change anything in
contrib/ so that it plays by whatever rules we set. There's an
expectation that contrib modules should be buildable with PGXS,
so they need to follow the rules.
regards, tom lane
