[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: [HACKERS] pg_upgrade + Extensions
From: Tom Lane <tgl () sss ! pgh ! pa ! us>
Date: 2015-08-31 23:58:24
Message-ID: 655.1441065504 () sss ! pgh ! pa ! us
[Download RAW message or body]
Andrew Dunstan <andrew@dunslane.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic