Jan Wieck <j...@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
