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)
CASE WHEN 'foo' = ANY(string_to_array(setting, ','))
ELSE setting || ',foo'
name = 'search_path'
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Remember to vote!
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not