Re: search_path vs extensions - Mailing list pgsql-hackers

From Greg Stark
Subject Re: search_path vs extensions
Date
Msg-id 4136ffa0905281220w5a226972i65b46e802c40487a@mail.gmail.com
Whole thread Raw
In response to Re: search_path vs extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: search_path vs extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 28, 2009 at 8:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: search_path vs extensions
Next
From: Tom Lane
Date:
Subject: Re: plperl error format vs plpgsql error format vs pgTAP