On 2016-09-04 11:55:06 -0400, Tom Lane wrote:
> [ warning, thread hijack ahead ]
>
> Stephen Frost <sfrost@snowman.net> writes:
> > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> >> I think this is a good change to pursue, and we'll likely want to do
> >> more similar changes in contrib. But I'm worried that what is logically
> >> a 10-line change will end up a 20 KiB patch every time.
>
> > We also created a new version to add the PARALLEL SAFE markings to the
> > functions. In general, I believe it's better to use a new version when
> > we're making these kinds of changes.
>
> It is becoming clear that the current extension update mechanism is kind
> of brute-force for this sort of change. I have no ideas offhand about a
> better way to do it, but like Peter, I was dismayed by the amount of pure
> overhead involved in the PARALLEL SAFE updates.
Agreed. I think one way, which a few extensions are taking, is to have a
base version and then incremental version upgrades. Currently CREATE
EXTENSION doesn't natively support that, so you have to concatenate the
upgrade scripts. I think it'd be great if we could add a 'baseversion'
property to the extension control file. When you create a new extension,
it'll start with the base version and then use the existing code to find
a path to upgrade to the target version. That also makes it a lot
easier to actually properly test extension upgrade paths, something
we've not really been good at.
> It's not only development overhead, either: users have to remember to
> run around and issue ALTER EXTENSION UPDATE for every extension they
> have, in every database they have it installed in. Anyone want to
> lay a side bet on how many users will actually do that? Given that
> the release notes don't currently suggest doing so, I'd be willing
> to put money on "none at all" :-(
Some certainly are, but I'm afraid that you're right that it's not too
many. If we don't make pg_upgrade upgrade all extensions, we should at
least have it generate a script doing so.
Greetings,
Andres Freund
