deprecating contrib for PGXN

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: deprecating contrib for PGXN
Date: 2011-05-17 20:31:42
Message-ID: 4DD2DB2E.5030409@darrenduncan.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I have missed it if this was discussed before but ...

Would now be a good time to start deprecating the contrib/ directory as a way to
distribute Pg add-ons, with favor given to PGXN and the like instead?

It would make sense to leave contrib/ alone for 9.1, but I believe that it
should start slimming down as we move towards 9.2, with any content that can
easily be migrated to PGXN/etc being taken out of contrib/ .

Or, the policy would be to stop adding new things to contrib/ except in the odd
case where that is surely the best place to put it, so only the legacy things
are there, and for the legacy things, they are removed case-by-case as workable
distributions for them first appear on PGXN/etc.

An analogy for policy here would be Perl 5 and what Perl modules it bundles.
The Perl modules that have the most business being bundled with Perl are those
minimal ones whose function is to go out to CPAN and install other modules.

Another analogy would be Parrot and languages implemented over it. Originally,
various language compilers were bundled with Parrot, and they gradually migrated
to their own distributions, Rakudo for example.

If this general policy of deprecating contrib/ is agreed on, then at the very
least the documentation shipped with 9.1 should mention it being deprecated and
talk about migration strategies. Or 9.1 could include a CPAN-like program that
makes it easier to install PGXN extensions, if that is applicable, so there is
an overlap period where people could get the legacy add-ons either way.

-- Darren Duncan

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2011-05-17 20:38:01 Re: adding a new column in IDENTIFY_SYSTEM
Previous Message Robert Haas 2011-05-17 19:14:28 Re: cache estimates, cache access cost