| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Subject: | Re: search_path vs extensions |
| Date: | 2009-05-29 20:49:32 |
| Message-ID: | 25641.1243630172@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <stark(at)enterprisedb(dot)com> writes:
> I'm actually not sure if we should allow extensions to be installed
> into separate schemas.
It's starting to seem that best practice is to install "public"
functions/etc into a common schema and "private" objects into an
extension-specific schema. The main problem with that from an extension
author's point of view is the need to explicitly qualify all references
to private objects, since they won't be in the search path. Which is
tedious, but doable.
Another issue is that doing that pretty much hard-wires what the
extension's private schema name is. Dunno how much we care, though.
You could certainly do this without any new search-path-related
features, but I wonder whether the system could provide any extra
support for it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2009-05-29 21:15:24 | Re: search_path vs extensions |
| Previous Message | Simon Riggs | 2009-05-29 20:37:47 | Re: Clean shutdown and warm standby |