Re: Modifying and solidifying contrib

On Tue, Jan 30, 2007 at 03:49:14PM -0500, 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".

+1 for name "extension."

> 2. namespace - I think the consensus is tending towards one or more per
> extension.

+1 here too. I understand that this may result in schemas that have
few functions in them. That's OK :)

> 3. install/uninstall support: Tom's proposal for an extension->schema
> map in the catalog will deal with that nicely, I think.

+1 :)

> 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).

The only "clever" bit I added was the CASE statement. Credit for the
rest belongs to Andrew at Supernews. It's not a bad thing for people
to keep around, either way. :)

> 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).

Hrm. This gets tricky. When things are mandated to be in their own
namespace, they need not check what everybody else's things are doing
each time, whereas when they go into the public schema... :P

> 6. they all need proper docs. READMEs and the like are nowhere near good
> enough.

Agreed. I'm thinking a new major section in the SGML docs is in order
with a subsection for each contrib/ piece underneath.

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

A subdirectory in src/tests/regression for each one?

> 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.

I don't think it would be too much trouble to do extensions the way we
now do tables and schemas in pg_dump, i.e. with multiple possible
regular expression entries like

--include-extension=

and

--exclude-extension=

where the includes get evaluated before the excludes.

Just my $.02 :)

Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!