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
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 |