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