| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Smitha Pamujula <smitha(dot)pamujula(at)iovation(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Grant Holly <grant(dot)holly(at)iovation(dot)com> |
| Subject: | Re: pg_upgrade + Extensions |
| Date: | 2015-08-31 23:58:24 |
| Message-ID: | 655.1441065504@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 08/31/2015 07:32 PM, Bruce Momjian wrote:
>> Still, I don't know how many people are doing this, but the right fix is
>> to get the names of the modules that are superceeded and tell pg_upgrade
>> to skip them.
> I don't think this knowledge should be hardcoded in pg_upgrade. I could
> see some point in a switch that would tell pg_upgrade a list of
> extensions to ignore.
That would not be terribly helpful for cases where the pg_upgrade call is
embedded in some wrapper script or other.
In any case, there is plenty of precedent for hard-coding knowledge about
specific version updates into pg_upgrade. The question here is whether
it's feasible to handle extensions that way. I think we could reasonably
expect to know about cases where a formerly separate extension got
integrated into core, but are there other cases where pg_upgrade would
need to ignore an extension in the old database?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2015-09-01 00:03:58 | Re: pg_upgrade + Extensions |
| Previous Message | Andrew Dunstan | 2015-08-31 23:52:24 | Re: pg_upgrade + Extensions |