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