On Jan 3, 2011, at 11:42 AM, Tom Lane wrote:
> It is, but I don't see any alternative. As Dimitri said, the .so will
> typically be installed by a packaging system, so we don't have any
> opportunity to run SQL code beforehand. In any case ...
>> The new .so should not be installed until the upgrade is been run.
> ... that flat out doesn't work. If the upgrade script tries to add
> functions that didn't exist in the old .so, it'll fail.
Right, what I'm saying is that `ALTER EXTENSION foo UPGRADE;` should install the .so, too, just before it runs the upgrade scripts.
In response to
pgsql-hackers by date
|Next:||From: Joel Jacobson||Date: 2011-01-03 19:46:02|
|Subject: Re: pg_dump --split patch|
|Previous:||From: Tom Lane||Date: 2011-01-03 19:42:25|
|Subject: Re: Upgrading Extension, version numbers (was: Extensions, patch v16) |