On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm not convinced that this is actually a requirement, or that doing it
> this specific way is a good solution. In particular, keeping the
> version number in the system catalogs seems pretty dubious. The common
> method for upgrading an already-installed contrib module just involves
> dropping in a new .so --- that's not going to change the system
> catalogs. It would likely be better to keep the version ID inside the
> .so file.
This is an interesting point. There are really two things here: the
.so version, and the version of the system catalog entries. For
example, imagine that an extension provides a single function, called
foo(). So we load up the .so and CREATE FUNCTION statement to match.
Later, the extension is so successful that the author writes a second
function, bar(). The new .so can (at least possibly) be used with the
old schema definitions, but the new schema definitions aren't
compatible with the old .so. The logical upgrade process is to swap
out the .so first, and then add update the catalog definitions.
On the other hand, if you were dropping a deprecated function, you'd
need to do the steps in reverse order.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
