Re: pg_upgrade does not upgrade pg_stat_statements properly
От | Jan Wieck |
---|---|
Тема | Re: pg_upgrade does not upgrade pg_stat_statements properly |
Дата | |
Msg-id | 3b757bb5-b481-3615-6d44-aaf0ab2813c8@wi3ck.info обсуждение исходный текст |
Ответ на | Re: pg_upgrade does not upgrade pg_stat_statements properly (Dave Cramer <davecramer@postgres.rocks>) |
Ответы |
Re: pg_upgrade does not upgrade pg_stat_statements properly
|
Список | 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 по дате отправления: