| From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Upgrading Extension, version numbers (was: Extensions, patch v16) |
| Date: | 2011-01-03 19:43:43 |
| Message-ID: | 3675513E-F09E-4DCC-8C96-4C17128A2084@kineticode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Best,
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2011-01-03 19:46:02 | Re: pg_dump --split patch |
| Previous Message | Tom Lane | 2011-01-03 19:42:25 | Re: Upgrading Extension, version numbers (was: Extensions, patch v16) |