From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jan Wieck <jan@wi3ck.info>
cc: Dave Cramer <davecramer@postgres.rocks>,
        Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
In-reply-to: <3b757bb5-b481-3615-6d44-aaf0ab2813c8@wi3ck.info>
References: <c4fc0792-1736-63e2-2447-ee2ed6e96b5b@wi3ck.info>
 <20210729161432.GN9600@momjian.us>
 <CAOBaU_ZRhXZN9qfWfyO+8pSLX6McFVwLYoDcsMtpvhd0pdiz3g@mail.gmail.com>
 <c23c3355-e7a3-4fbe-2521-32d5944b48b3@wi3ck.info>
 <20210730020257.jpvunvworyqsaz43@nol>
 <CADK3HHJ4BmJqB+BLHa-UL464q0_dLxkTA6sB51JAp6DOMpfufw@mail.gmail.com>
 <20210730103945.nc2zl74v5czy2qwd@nol>
 <CADK3HHKz4ruqmqiph2cLvg53AibAPsEyen4uDXe1h5bu-nwWjg@mail.gmail.com>
 <20210730110728.tqt3oeohyvtuqqk7@nol>
 <CADK3HHJj3Zw7rHP=WzLKKg8_o-KmNH48gsxDaVPFB+gLzySBJg@mail.gmail.com>
 <20210730112832.wt3zdv32gllohope@nol>
 <CADK3HHKGk-YZ-FR2_nY+GeBKmYPuGbS33KUE2NM+F9oHQby_Hg@mail.gmail.com>
 <3b757bb5-b481-3615-6d44-aaf0ab2813c8@wi3ck.info>
Comments: In-reply-to Jan Wieck <jan@wi3ck.info>
	message dated "Fri, 30 Jul 2021 12:43:04 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1009428.1627664712.1@sss.pgh.pa.us>
Date: Fri, 30 Jul 2021 13:05:12 -0400
Message-ID: <1009429.1627664712@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1009429.1627664712%40sss.pgh.pa.us>
Precedence: bulk

Jan Wieck <jan@wi3ck.info> writes:
> 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.

That idea cannot get off the ground.  We've spent ten years telling
people they can use whatever version-numbering scheme they like for
their extensions; we can't suddenly go from that to "you must use
exactly this scheme".

I don't see the need for it anyway.  What is different from just
putting the update actions into an extension version upgrade
script created according to the current rules, and then setting
that new extension version as the default version in the extension
build you ship for the new server version?

			regards, tom lane