Tom,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> [ warning, thread hijack ahead ]
quite.
> 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.
To make the patches smaller, it seems that we'd need a way to avoid the
removal and re-addition of the entire install script and a way to avoid
having to add a new upgrade script.
Perhaps if the versioned install script was actually a non-versioned
install script in the source tree, and the Makefile simply installed it
into the correct place, then we could eliminate that part. (All very
hand-wavy, I've not looked at what it'd take to do.)
I don't have any great answers for the upgrade script off-hand. We
could come up with a way for one file to handle multiple upgrade
options, but that doesn't really make the patch any smaller.
> 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" :-(
I agree, that's also an issue.
> I wonder whether pg_upgrade ought to be changed to attempt upgrading
> every extension after it's completed the basic migration. Or at
> least offer a script containing all the needed commands.
I like the idea of having an option and documentation to go along with
it. Hopefully that will help administrators at least realize that it's
something they'll want to look at doing.
> Anyway, it's not this particular patch's job to do better, but we
> oughta think about better ways to do it.
Agreed.
Thanks!
Stephen
