Andrew Dunstan <and...@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. > 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' -- Envoyé de mon téléphone, excusez la brièveté. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
