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 [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
