| From: | Greg Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: search_path vs extensions |
| Date: | 2009-05-28 19:20:00 |
| Message-ID: | 4136ffa0905281220w5a226972i65b46e802c40487a@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 28, 2009 at 8:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It also seems to me that we're getting seriously sidetracked from the
>> dependency-tracking part of this project which seems to me to be a
>> much deeper and more fundamental issue.
>
> I thought that part was a pretty simple problem, actually. Have an
> object representing the module, make sure each component object in the
> module has an AUTO dependency link to that object. Where's the
> difficulty?
Is that really a complete answer? How do we deal with upgrading an
extension to a more recent version? What happens to objects in the
database which depend on objects from the extension?
Can we suspend the normal rules for dependency tracking while
uninstalling the old version, install the new version, then check that
all the dependencies which were left hanging from the old one can be
satisfied by similarly named objects in the new one and redirect them?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-05-28 19:22:29 | Re: plperl error format vs plpgsql error format vs pgTAP |
| Previous Message | Tom Lane | 2009-05-28 19:16:21 | Re: search_path vs extensions |