Re: Modifying and solidifying contrib

On Mon, Jan 29, 2007 at 04:44:44PM -0500, Andrew Dunstan wrote:
> Bruce Momjian wrote:
> >Andrew Dunstan wrote:
> >
> >>Bruce Momjian wrote:
> >>
> >>>Keep in mind all contrib loads into public, and I don't remember any
> >>>namespace conflict issues in the past.
> >>>
> >>That is beside the point. Of course there haven't been conflicts -
> >>precisely because a single group controls the whole lot. What I
> >>said was that we should behave as sane third party extension
> >>authors would, namely to use their own namespace to protect
> >>themselves from conflicts with other unknown extensions. It's
> >>called setting a good example or eating your own dog food.
> >
> >The problem I see controlling per-user search_path if +10
> >extensions are instlalled, and you want them always to be available
> >by default.
>
> This suggests maybe we need to look at beefing up a few things. For
> example, an alias facility that provided a name in schema X for
> things in schema Y would help lots here. (You want everything
> visible? Just alias it in public.) ISTR such things in DB2, although
> it's now many years since I laid hands on it, so my memory could
> well be very faulty.
>
> Also, ability to append to the search path rather than just set it
> could help, as might ability to add names of non-existent schemas
> (which would be ignored at run time when found not to exist).

You can already do this via the following (baroque, but idempotent)
method:

UPDATE
pg_catalog.pg_settings
SET
setting =
CASE WHEN 'foo' = ANY(string_to_array(setting, ','))
THEN setting
ELSE setting || ',foo'
END
WHERE
name = 'search_path'
;

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

Remember to vote!