Re: Modifying and solidifying contrib

On Wed, Jan 31, 2007 at 09:31:00AM -0500, Andrew Dunstan wrote:
> David Fetter wrote:
> >On Tue, Jan 30, 2007 at 03:49:14PM -0500, Andrew Dunstan wrote:
> >>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. :)
>
> I dislike on principle things that mangle the catalogs directly. As
> soon as I see one I think "why aren't we providing an SQL command
> for that?" By and large, I think users should be able to work as
> though the catalog were not visible, or at least not directly
> writable.

So are you proposing user-visible functions in pg_catalog like the
following?

append_to_search_path(role NAME, database NAME, paths NAME[])
prepend_to_search_path(role NAME, database NAME, paths NAME[])
remove_from_search_path(role NAME, database NAME, paths NAME[])

The above is how I'm picturing how this would fit in with the TODO of
allowing things to be set on a per-role-and-database basis. There
could be two-argument short-cuts of each of those which would do the
above for the current user.

> >>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
>
> Why is it tricky? This is for legacy only, i.e. for object we know
> of today. Any future objects in existing extensions, or objects in
> new extensions, should not have this support - they should use their
> own namespaces, pure and simple.

OK

> >>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?
>
> No. One of the reasons for us to maintain some standard extensions
> is to act as exemplars. You should be able to build, install and
> test an extension without having a complete source tree present. So
> each extension should keep its own sql and expected directory as
> now, I think.

Right :)

> >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.
>
> OK, as long as --exclude-extension has an "all" option, or we have a
> --no-extensions option also.

While we're at it, both cases should be straight-forward to do.

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

Remember to vote!