Re: [PATCH] Support % wildcard in extension upgrade filenames

From: Regina Obe <r(at)pcorp(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Sandro Santilli <strk(at)kbt(dot)io>
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Date: 2022-11-22 19:03:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation: tested, passed

I reviewed this patch

Most look good to me. The only things that have changed since last I reviewed this, with the new patch is

1) wildcard_upgrades=true is no longer needed in the control file and will break if present. This is an expected change, since we are now going strictly by presence of % extension upgrade scripts per suggestions
2) The meson build issue has been fixed. Cirrus is passing on that now. I'm still fiddling with my meson setup, so didn't personally test this.

3) The documentation has been updated to no longer include wildcard_upgrades as a variable for control file.

and has this text now describing it's use:

The literal value % can be used as the old_version component in an extension update script for it to match any version. Such wildcard update scripts will only be used when no explicit path is found from old to target version.

Given that a suitable update script is available, the command ALTER EXTENSION UPDATE will update an installed extension to the specified new version. The update script is run in the same environment that CREATE EXTENSION provides for installation scripts: in particular, search_path is set up in the same way, and any new objects created by the script are automatically added to the extension. Also, if the script chooses to drop extension member objects, they are automatically dissociated from the extension.

I built the html docs but ran into a lot of warnings I don't recall getting last time. I think this is just my doc local setup is a bit messed up or something else changed in the doc setup.

My main gripe with this patch is Sandro did not increment the version number of it, so it's the same name as an old patch he had submitted before.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2022-11-22 20:01:37 Re: fixing CREATEROLE
Previous Message Robert Haas 2022-11-22 19:02:16 Re: Damage control for planner's get_actual_variable_endpoint() runaway