On Thu, 12 May 2005 02:44 pm, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Andrew Dunstan wrote:
> >> First, I *really* wish we'd call it something else. Contrib conveys
> >> "unsupported" to people.
>
[snip]
> Which is as it should be, I think. Contrib is essentially the "not
> quite ready for prime time" area. If it were 100% up to speed then
> it'd be in the core backend already ... while if we required it to be
> 100% in advance, then it'd not have gotten out there in the first place.
>
At which point do things move from no being 100% to being 100%. From
what I understand some of the contrib modules have been there for a very
long time. Some of the may be solved other ways. eg the new system views and
dbsize.
Other things like pg_crypto may enable simple things like changing somebodies
username without redoing their password, as we could use those functions instead of the current ones.
This may make some of our pg_shadow friends (with regard to recentish security threads)
a bit happier as well.
I suppose the question is, at what point are contrib modules re-reviewed for inclusion
into core? And if they are continuing not to make it, is there something else that should
be done with them?
> The real issue seems to be that we have a disconnect between what is
> presently in contrib and what is on gborg or pgfoundry. There are
> certainly many contrib modules that are only there on seniority: if
> they were submitted today then they'd have gotten put on pgfoundry.
> But I'm not sure that there's much value in an enforced cleanup.
Maybe not an enforced cleanup. But if there are people who manage
certain modules, it may be work asking them the question about getting
their contrib module onto pgfoundry if that is the best place for it. And then
giving them a little bit of support in doing it. eg, getting the cvs history out of the PostgreSQL cvs
tree.
Regards
Russell Smith
