Re: RFC: Remove contrib entirely

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Remove contrib entirely
Date: 2015-05-29 19:30:42
Message-ID: CAFj8pRBeW_57ypmigkrP+EB1H_qtdWMccFYV2_8qtcFkEMcG_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-05-29 21:20 GMT+02:00 Joshua D. Drake <jd(at)commandprompt(dot)com>:

>
> On 05/29/2015 11:27 AM, Jeff Janes wrote:
>
> It would be less confusing for users. Contrib modules seem to be
>> first class extensions, leaving doubt on other extensions.
>>
>>
>> Presumably there are still going to be some extensions maintained by
>> -hackers, and some not. I don't think we are going to change that, so
>> the difference will still need to be explained, regardless of what words
>> are used. And people *should* have doubts about other extensions.
>> Couldn't any talented programmer write an extension which gives them a
>> backdoor into the deployer's system, and then upload it to github?
>>
>
> Yes, it is called Open Source development.
>
>
>> I would certainly be cautious about installing any old extension I found
>> some some place on the internet.
>>
>> But the fact they aren't in core make them not fully trusted by some
>> users.
>>
>
> No. This is completely wrong thinking. If you are compiling this stuff
> from source you are taking that risk on yourself.
>
> Most people are not compiling from source, they are installing from a
> distribution (or downloading a distribution package).
>
>
>> Trying to explain all that in a training is a PITA. It would be much
>> less confusing if they were either in core or in their own repository.
>>
>> Several of the contrib modules should be kept in tight sync with src or
>> else testing and debugging would be a disaster. Putting them in
>> different git repositories wouldn't work well. Unless those would among
>> the ones moved to "core".
>>
>>
> Note: I actually don't care if the current contrib gets pushed into core
> proper and is default installed.
>
> I care about this idea that contrib exists. It isn't needed and leads to a
> discussion like this one (or the pg_audit), almost every release.
>
> Contrib made sense years ago. It does not any longer. Let's put the old
> horse down and raise a new herd of ponies on a new pasture.
>

Still there is strong sense - it is a referential implementation of our
extension API. We need it to find regressions, changes. I don't believe so
external extensions can do it. Only PostGIS is massively accepted and
developed by more than few people. Personally I am thinking so removing
contrib is not good idea.

Pavel

>
> 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.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-05-29 19:31:46 Re: [CORE] postpone next week's release
Previous Message Andres Freund 2015-05-29 19:27:41 Re: Need Force flag for pg_drop_replication_slot()