Re: [PATCH] Remove useless USE_PGXS support in contrib

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [PATCH] Remove useless USE_PGXS support in contrib
Дата
Msg-id 51BB1B6E.2070705@dunslane.net
обсуждение исходный текст
Ответ на Re: [PATCH] Remove useless USE_PGXS support in contrib  (Peter Eisentraut <peter_e@gmx.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  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
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 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)   src/extension.c    sql/extension.sql    test/sql/extension.sql    test/expected/extension.out
 


cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Benedikt Grundmann
Дата:
Сообщение: Re: MD5 aggregate
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Patch for fail-back without fresh backup