| 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: | Whole Thread | Raw Message | 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 |