Re: pg_upgrade does not upgrade pg_stat_statements properly - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: pg_upgrade does not upgrade pg_stat_statements properly
Date
Msg-id 3b757bb5-b481-3615-6d44-aaf0ab2813c8@wi3ck.info
Whole thread Raw
In response to Re: pg_upgrade does not upgrade pg_stat_statements properly  (Dave Cramer <davecramer@postgres.rocks>)
Responses Re: pg_upgrade does not upgrade pg_stat_statements properly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 7/30/21 7:33 AM, Dave Cramer wrote:
> 
> 
> 
> 
>     Yes, but as I said twice only if the currently installed version is
>     different
>     from the default version.  Otherwise ALTER EXTENSION UPGRADE is a no-op.
> 
> 
> Ah, ok, got it, thanks. Well I'm not sure how to deal with this.
> The only thing I can think of is that we add a post_upgrade function to 
> the API.
> 
> All extensions would have to implement this.

An alternative to this would be a recommended version number scheme for 
extensions. If extensions were numbered

    MAJOR_SERVER.MAJOR_EXTENSION.MINOR_EXTENSION

then pg_upgrade could check the new cluster for the existence of an SQL 
script that upgrades the extension from the old cluster's version to the 
new current. And since an extension cannot have the same version number 
on two major server versions, there is no ambiguity here.

The downside is that all the extensions that don't need anything done 
for those upgrades (which I believe is the majority of them) would have 
to provide empty SQL files. Not necessarily a bad thing, as it actually 
documents "yes, the extension developer checked this and there is 
nothing to do here."


Regards, Jan

-- 
Jan Wieck



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: Jan Wieck
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly