Re: modules - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: modules
Date
Msg-id 47F69AFC.9060002@dunslane.net
Whole thread Raw
In response to Re: modules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: modules  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers

Tom Lane wrote:
>
> IMHO, the ideal situation would be that the only stuff in contrib is
> stuff that needs to be maintained together with the core code --- an
> example is pg_controldata, because it looks at data structures that
> we change on a frequent basis.  We need to be looking for ways to
> increase the status of stuff that doesn't come with the core distro,
> not create an even stronger gap between the "ins" and the "outs".
>
>             
>   

Well, I think we need some more than that, although possibly we don't 
need everything that's in contrib now. I think it's important that we 
keep a few in the core distribution as exemplars of the various module 
types (broadly: PLs, types, function libraries).

The example I have in mind is Perl, as I have referred to before. It 
comes with a number of useful modules (e.g. File::Find, and CGI) that 
don't have to be in the perl core distribution but are very widely used 
and so having them there makes some sense.

I do agree that we need to embark on some education to help make 
non-core modules more acceptable to the world at large. A standard build 
and install framework and a somewhat trustable repository would help a 
lot with that. If people want to start building out stuff now on the "if 
we build it they will come" theory, then that's where I'd personally 
encourage them to put effort.

cheers

andrew


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Garbage pad bytes within datums are bad news
Next
From: Tom Lane
Date:
Subject: Re: Garbage pad bytes within datums are bad news