Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... 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.
True. Consider a situation like an RPM upgrade: it's going to drop in a
new .so version, *and nothing else*. It's pure fantasy to imagine that
the RPM script is going to find all your databases and execute some SQL
commands against them. Since a large number of bug-fix cases do require
only a .so update, not being able to track the .so version seems like
it's missing most of the argument for having version tracking at all.
(In the RPM case, the RPM infrastructure would be able to tell you
which version you had installed, so I'm not sold that PG needs to
duplicate that.)
regards, tom lane
