Re: [PATCH] Remove useless USE_PGXS support in contrib

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [PATCH] Remove useless USE_PGXS support in contrib
Дата
Msg-id 51BC4C04.9030307@dunslane.net
обсуждение исходный текст
Ответ на Re: [PATCH] Remove useless USE_PGXS support in contrib  (Cédric Villemain <cedric@2ndquadrant.com>)
Ответы Re: [PATCH] Remove useless USE_PGXS support in contrib  (Cédric Villemain <cedric@2ndquadrant.com>)
Re: [PATCH] Remove useless USE_PGXS support in contrib  ("David E. Wheeler" <david@justatheory.com>)
Список 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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: pluggable compression support
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: pluggable compression support