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

From: LEO HSU <lr(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-10 01:10:52
Message-ID: 166804265261.1126.12857252111207883556.pgcf@coridan.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

PURPOSE:

This feature is intended to allow projects with many micro versions that do the same thing, be able to ship much fewer files by specifying less granular stopping.
One of the projects that will benefit from this is the PostGIS project. Currently we ship over 300 extension scripts per version which are currently just symlinks to the same file.
Part of the reason for that is our changes are dependent on both PostgreSQL version and PostGIS version, so a simple upgrade that only considers say PostGIS 3.2.0--3.3.1 is not sufficient.
Also much of the time, our function definitions don't change in micros, but yet we need to ship them to allow users to properly upgrade.

This feature will allow us to get rid of all these symlinks or 0-byte files.

I've tested this feature against the PostgreSQL master branch on mingw64 gcc 8.1.

BASIC FEATURES

1) As stated, this feature only works if in the .control file, has a line:

wildcard_upgrades = true

2) It does nothing different if the line is missing or set to false.

3) If there is such a line and there is no other path that takes an extension from it's current version to the requested version, then it will use the wildcard script file.

TESTING

AUTOMATED TESTS
I have confirmed tests are in place.
However the tests do not run when I do
make check (from the root source folder)

or when I do

make installcheck-world

To run these tests, I had to

cd src/test/modules/test_extensions
make check

and see the output showing:

============== running regression test queries ==============
test test_extensions ... ok 186 ms
test test_extdepend ... ok 97 ms

I confirmed the tests are in test_extensions, which has always existed.
So I assume why it's not being run in installcheck-world is something off with my configuration
or it's intentionally not run.

MANUAL TESTS
I also ran some adhoc tests of my own to confirm the behavior. and checking with
SET client_min_messages='DEBUG1';

To confirm that the wildcard script I have only gets called when there is no other path that will take the user to the new version.
I created my own extension
wildtest

1) I confirmed It only understands % as a complete wildcard for a version number

So this is legal
wildtest--%--2.0.sql

This does nothing
wildtest--2%--2.0.sql

2) I confirmed that if you have a path such as

wildtest--2.0--2.2.sql
wildtest--%--2.2.sql

then the exact match trumps the wildcard. In the above case if I am on 2.0
and going to 2.2, the wildtest--2.0--2.2.sql script is used instead of the
wildtest--% one.

3) It is not possible to downgrade with the wildcard. For example I had
paths
wildtest--%--2.1.sql

and I was unable to go from a version 2.2 down to a version 2.1.

DOCUMENTATION

I built the html docs and confirmed that in the section of the docs where it defines valid properties of extension files it now includes this line:

wildcard_upgrades (boolean)

This parameter, if set to true (which is not the default), allows ALTER EXTENSION to consider a wildcard character % as matching any version of the extension. Such wildcard match will only be used when no perfect match is found for a version.

The new status of this patch is: Ready for Committer

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-11-10 01:29:40 Re: Allow file inclusion in pg_hba and pg_ident files
Previous Message Andres Freund 2022-11-10 01:03:13 Re: heavily contended lwlocks with long wait queues scale badly