Re: Modifying and solidifying contrib

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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)