Re: search_path vs extensions

Greg Stark <stark(at)enterprisedb(dot)com> writes:
> 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?

Well, if it's only a code change then you install a newer version of the
.so and you're done. If the extension upgrade requires altering any
SQL-level properties of the module's objects then I'd expect the
extension author to provide a SQL script to do that.

Obviously there is value in being able to do things like add new objects
to an existing module, but we hashed out the mechanisms for that long
ago. IIRC the proposed syntax was along the lines of

CREATE EXTENSION foo;

BEGIN EXTENSION foo;

... anything created here is automatically tagged as belonging
to foo ...

END EXTENSION foo;

where you can repeat the BEGIN/END later to add more objects. An
alternative was to not have BEGIN/END but instead a GUC variable that
you can SET to the name of the extension currently being added to.
(The main advantage of that is that the state isn't hidden, but easily
checkable via existing commands.)

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

Sounds like a solution in search of a problem. Why would that be a good
idea?

regards, tom lane