From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | 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-14 13:32:30 |
Message-ID: | 51BB1B6E.2070705@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-06-14 13:36:36 | Re: Patch for fail-back without fresh backup |
Previous Message | Tom Lane | 2013-06-14 13:21:52 | Re: Patch for fail-back without fresh backup |