From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndQuadrant(dot)com> |
Cc: | Stuart Bishop <stuart(at)stuartbishop(dot)net>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7661: pgstattuple from unpackaged fails on old installation |
Date: | 2012-11-15 14:49:42 |
Message-ID: | 14882.1352990982@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Craig Ringer <craig(at)2ndQuadrant(dot)com> writes:
> On 11/15/2012 03:32 PM, Stuart Bishop wrote:
>>> That's a known issue with several of the extensions. You need to upgrade
>>> the contrib module install to the current version, *then* wrap the
>>> unpackaged contrib module into an extension with "FROM UNPACKAGED".
>> Yeah, just thought I'd stick it in the... umm... bugtracker, as so far
>> 'FROM unpackaged' has failed in 66% of up updates. Is the real
>> solution is for the foo--unpackaged--1.0.sql script to recreate
>> missing objects before adding them to the extension?
> Extensions were created because upgrading DBs that used contrib modules
> was a painful mess.
Yeah. The goal we set ourselves when making the foo--unpackaged scripts
was only to be able to upgrade from the immediately preceding form of
the contrib module. I think it's probably true that in many cases
adding CREATE OR REPLACE-type commands could allow upgrading from
earlier versions as well. But it would be a lot of work to research
what's needed and create/test a patch, and it would be work whose value
lessens with every passing day. If there's somebody out there who's
sufficiently annoyed to do that work, have at it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | mtesfaye | 2012-11-15 16:48:34 | BUG #7662: INSERT rule doesn't work as expected |
Previous Message | Amit kapila | 2012-11-15 13:59:12 | Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown |