Re: [PATCH] Remove useless USE_PGXS support in contrib - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: [PATCH] Remove useless USE_PGXS support in contrib |
Date | |
Msg-id | 51BC4C04.9030307@dunslane.net Whole thread Raw |
In response to | Re: [PATCH] Remove useless USE_PGXS support in contrib (Cédric Villemain <cedric@2ndquadrant.com>) |
Responses |
Re: [PATCH] Remove useless USE_PGXS support in contrib
Re: [PATCH] Remove useless USE_PGXS support in contrib |
List | pgsql-hackers |
On 06/15/2013 06:24 AM, Cédric Villemain wrote: > Andrew Dunstan <andrew@dunslane.net> a écrit : > >> On 06/14/2013 08:35 AM, Peter Eisentraut wrote: >>> On 6/13/13 9:20 PM, amul sul wrote: >>>> Agree, only if we consider these contrib module is always gonna >> deployed with the postgresql. >>>> But, what if user going to install such module elsewhere i.e. not > >from contrib directory of pg source. >>> Why would anyone do that? >>> >>> >> Maybe they wouldn't. >> >> I do think we need to make sure that we have at least buildfarm >> coverage >> of pgxs module building and testing. I have some coverage of a few >> extensions I have written, which exercise that, so maybe that will >> suffice. If not, maybe we need to have one module that only builds via >> pgxs and is build after an install (i.e. not via the standard contrib >> build). > I agree, I found very useful to have all the provided extensions build with PGXS to debug it. > It also offers a good set of natural regression tests. > >> 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) > >> 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. 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. cheers andrew
pgsql-hackers by date: