Re: search_path vs extensions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-28 01:24:33
Message-ID: 603c8f070905271824p924d542ucc665e5b343e37a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 27, 2009 at 9:01 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Sure.  I think that having better search path management would be a
> wonderful thing; it would encourage people to use schema more in general.
>
> However, that doesn't mean that I think it should be part of the extensions
> design, or even a gating factor.

Agreed, I think this is largely a tangent.

However, since we're on that tangent, I'm not completely convinced
that additional lists of search paths that get prepended or appended
to the main search path are the right way to go. It seems like that's
just chopping up the problem into smaller bits without really fixing
anything. I wonder if the right solution might be to associate with
each schema a list of other schemas to be searched if the object isn't
found in that schema. This means that the contents of search_path
would really become the roots of the trees of schemas to be searched.

Then we could provide DDL commands to do things like:

ALTER SCHEMA pg_extensions INHERIT SCHEMA my_new_extension;
ALTER SCHEMA pg_extensions NO INHERIT SCHEMA extension_i_want_to_remove;

</handwaving>

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-05-28 01:26:28 Re: User-facing aspects of serializable transactions
Previous Message Kevin Grittner 2009-05-28 01:18:18 Re: PostgreSQL Developer meeting minutes up