[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Modifying and solidifying contrib
From:       David Fetter <david () fetter ! org>
Date:       2007-01-31 17:35:38
Message-ID: 20070131173538.GD24354 () fetter ! org
[Download RAW message or body]

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@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
[prev in list] [next in list] [prev in thread] [next in thread]