Skip site navigation (1) Skip section navigation (2)

Re: Modifying and solidifying contrib

From: David Fetter <david(at)fetter(dot)org>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>,"Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com>,Michael Glaesemann <grzm(at)seespotcode(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Modifying and solidifying contrib
Date: 2007-01-31 17:35:38
Message-ID: 20070131173538.GD24354@fetter.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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!

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-01-31 17:41:57
Subject: Re: stack usage in toast_insert_or_update()
Previous:From: Tom LaneDate: 2007-01-31 15:11:13
Subject: Re: [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group