> >> I don't really like the directory layout we use for these modules
> >> anyway, so I'm not sure they constitute best practice for extension
> >> builders. Lately I have been using an extension skeleton that looks
> >>
> >> something like this:
> >> License
> >> Readme.md
> >> META.json (for pgxn)
> >> extension.control
> >> Makefile
> >> doc/extension.md (soft linked to ../Readme.md)
> >
> > This makes mandatory to have a MODULEDIR defined or a rule to rename it
> > with the extension name suffixed.
>
> Of course, for extension foo this would actually be foo.md. It installs
> just fine like that. The makefile template has:
>
> DOCS = $(wildcard doc/*.md)
Oh! yes, I missed the soft link.
> >> src/extension.c
> >> sql/extension.sql
> >
> > It is (was) the default place for regression tests....I am not sure it is
> > a good thing to shuffle that. Also, you don't do 'c/source.c'
>
> The sql here is the sql to install the extension, not part of the build
> nor part of the tests.
I am interested by this topic, since we have Extensions we invite users to
increase the usage of them. So going a step forward with a better layout is
definitively something to do.
What do you suggest for the previous usage ? we have a hard rule to try to put
libdir in *sql.in files for example.
> Some time ago I fixed pg_regress to honor --inputdir and --outputdir
> properly, so my Makefile template has this:
>
> REGRESS_OPTS = --inputdir=test --outputdir=test \
> --load-extension=$(EXTENSION)
> ...
> override pg_regress_clean_files = test/results/
> test/regression.diffs test/regression.out tmp_check/ log/
>
>
> That keeps the testing stuff out of the way quite nicely.
>
> You might not like this pattern, but I find it much saner that what we
> currently use. I certainly don't claim it's perfect.
I am interested by this topic, since we have Extensions we invite users to
increase the usage of them. So going a step forward with a better layout is
definitively something to do. I have no strong assumption on what the ideal
layout is, 'your' and pgxn layout are good and I won't vote against suggesting
to use them (and improve PGXS to match those suggestions).
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation