| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(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 02:02:59 |
| Message-ID: | 4A1DF0D3.8@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert,
> 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.
See, that strikes me a completely unmanageable and likely to give rise
to application security holes. But you're a smart guy ... so, *why*
would that be a better idea than some superuser settings? What am I not
thinking of?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-05-28 02:04:25 | Re: GEQO: ERX |
| Previous Message | Josh Berkus | 2009-05-28 02:00:56 | Re: sun blade 1000 donation |