Re: RFC: Remove contrib entirely

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Remove contrib entirely
Date: 2015-05-28 20:05:24
Message-ID: 55677504.8020401@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 05/28/2015 12:35 PM, Stephen Frost wrote:
> JD,

> What we would need for this is an 'extensions' directory, or similar,
> and a clear definition of what the requirements are around getting into
> it are. With that, we could decide for each module currently in contrib
> if it should go into the 'extensions' directory. I'm not sure that we
> would necessairly have to remove the contrib module or any modules which
> are deemed to not be appropriate for the 'extensions' directory.

I am suggesting that things like citext be made a type proper. No
install required. For things like pg_stat_statements of course there
could be configuration required (need to add it to the preload) but it
is automatically installed with the packages.

>
>> I am sure there will be plenty of fun to be had with what should or
>> shouldn't be merged into core. I think if we argue about the
>> guidelines of how to analyze what should be in core versus the
>> merits of any particular module, life will be easier. Here are some
>> for a start:
>>
>> A. Must have been in contrib for at least two releases
>> B. Must have visible community (and thus use case)
>
> I don't particularly like having a time-based requirement drive what's
> in which area, especially one that's double the length of our major
> release cycle.

I think there is only one or two contrib modules that don't actually fit
requirement A.

>
>> 2. Push the rest out into a .Org project called contrib. Let those
>> who are interested in the technology work on them or use them. This
>> project since it is outside of core proper can work just like other
>> extension projects. Alternately, allow the maintainers push them
>> wherever they like (Landscape, Github, Savannah, git.postgresql.org
>> ...).
>
> That's an interesting idea, but it's unclear how this would be any
> different from PGXN..?

PGXN is CPAN not Perl or DBD::Pg.

It is actually a compliment to PGXN because it is still needed and
needed more because that is where you are going to get the "latest and
greatest" of the modules.

Sincerely,

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2015-05-28 20:06:46 Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Previous Message Robert Haas 2015-05-28 19:56:36 Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1