Re: Extensions, patch v16

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions, patch v16
Date: 2010-12-10 18:10:57
Message-ID: AANLkTimU59a22BXVrjy3TfMqpnAt-D=kCFpsF6Yv6Szo@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-10 18:20:29 Re: Extensions, patch v16
Previous Message Tom Lane 2010-12-10 18:06:59 Re: Why percent_rank is so slower than rank?