Re: Modifying and solidifying contrib - Mailing list pgsql-hackers

There was also mention of having a means to tell pg_dump not to dump  
extensions...

On Jan 30, 2007, at 2:49 PM, Andrew Dunstan wrote:

> 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
>
>
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>               http://archives.postgresql.org
>

--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)