Re: Modifying and solidifying contrib

Bruce Momjian wrote:
> Joshua D. Drake wrote:
>   
>>> This seems like a good first step in growing a packaging 
>>> infrastructure. I'd rather grow it organically than try to design it 
>>> all up front.
>>>
>>>       
>> I am in Denver and have spotty inet access so forgive me. So where does 
>> this above leave us? What are we doing?
>>     
>
> I was kind of unclear on that too.  It seems we are trying to address
> several issues:  visibility of contrib, installation of contrib, etc.
> We discussed whether we put the functions in public, a schema for all
> contrib, or a schema for each contrib module, and then there was the
> discussion of how to configure someone using ten /contrib modules, or at
> least wanting them all to be accessible.  
>
> And then there was the idea of allowing schema permissions to control
> access, so perhaps we could install more of /contrib by default, and
> allow the administrator to just enable/disable them via permissions. 
> Personally, I think that might be the best approach because it allows us
> to eliminate the install process, but doesn't make the database less
> secure --- the administrator enables/disables them at runtime, or at
> least could.
>
>   

The issues I see are:

1. the 'thing" name - the only name I have not seen some objection to is 
"extension".
2. namespace - I think the consensus is tending towards one or more per 
extension.
3. install/uninstall support: Tom's proposal for an extension->schema 
map in the catalog will deal with that nicely, I think.
4. visibility/searchpath issues. I don't think long search paths are a 
huge issue, but I think we can make life a bit easier by tweaking 
searchpath support a bit (David's clever SQL notwithstanding).
5. legacy support - we need an option to load existing extensions to the 
public schema as now, or support for aliases/synonyms (the latter might 
be good to have regardless).
6. they all need proper docs. READMEs and the like are nowhere near good 
enough.

Richard mentioned special testing requirements, but I don't see why we 
can't continue to use our standard regression mechanism.

Mention has also been made of autoloading extensions with initdb. A case 
could perhaps be made for doing it in createdb - maybe not every db 
needs ltree, say. OTOH, if it's sitting quietly in its own schema than 
it's probably not doing any harm either, so maybe initdb should just 
load all the extensions it finds, and as you say make one less hoop to 
make people jump through. If we do that I think at least we'd need an 
option to inhibit autoloading.

cheers

andrew