Re: pg_upgrade + Extensions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_upgrade + Extensions
Date
Msg-id 55E4E8B8.30706@dunslane.net
Whole thread Raw
In response to Re: pg_upgrade + Extensions  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade + Extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 08/31/2015 07:32 PM, Bruce Momjian wrote:
> On Mon, Aug 31, 2015 at 07:28:00PM -0400, Andrew Dunstan wrote:
>>
>> On 08/31/2015 07:21 PM, David E. Wheeler wrote:
>>> On Aug 31, 2015, at 4:20 PM, Bruce Momjian <bruce@momjian.us> wrote:
>>>
>>>>> I think it would help if its noted somewhere in the document as it would have
>>>>> helped us save some time understanding why it was failing and why it was
>>>>> looking for json_build.
>>>> The problem is that this is a rare case where you had an extension that
>>>> was later included in Postgres.
>>> Maybe not so rare. Thanks to Andrew, we’ve had to do this for both 9.2-9.3 (json_object) and 9.3-9.4 (json_build).
>>>
>>
>> Yeah, a lot of people don't like to wait for new stuff. :-)
> It might make the most sense to mention this method in the release notes
> of the extension.  However, I assume they are not using the extension in
> the new server so their is no release to look at.
>
> 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.

cheers

andrew



pgsql-hackers by date:

Previous
From: Smitha Pamujula
Date:
Subject: Re: pg_upgrade + Extensions
Next
From: Tom Lane
Date:
Subject: Re: pg_upgrade + Extensions