Re: [PATCH] Remove useless USE_PGXS support in contrib

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Cédric Villemain <cedric(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Remove useless USE_PGXS support in contrib
Date: 2013-06-15 11:12:04
Message-ID: 51BC4C04.9030307@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 06/15/2013 06:24 AM, Cédric Villemain wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2013-06-15 11:25:49 Re: pluggable compression support
Previous Message Hannu Krosing 2013-06-15 11:11:47 Re: pluggable compression support