Robert Haas <robertmh...@gmail.com> writes: > On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers