From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extensions, patch v16 |
Date: | 2010-12-10 18:21:56 |
Message-ID: | 04229729-4C01-4CEE-B95D-21463D547FEF@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 10, 2010, at 10:20 AM, Tom Lane wrote:
> 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.
Sometimes there will be changes to the SQL, too. How does that work with CREATE EXTENSION? Do I install the upgrade, then run CREATE EXTENSION to get the latest SQL script to run? But then all the objects already exist…
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Igrishin | 2010-12-10 18:26:11 | Re: Extended query protocol and exact types matches. |
Previous Message | Tom Lane | 2010-12-10 18:20:29 | Re: Extensions, patch v16 |