Re: [PATCH] Support % wildcard in extension upgrade filenames - Mailing list pgsql-hackers

From LEO HSU
Subject Re: [PATCH] Support % wildcard in extension upgrade filenames
Date
Msg-id 166804265261.1126.12857252111207883556.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Re: [PATCH] Support % wildcard in extension upgrade filenames  (Sandro Santilli <strk@kbt.io>)
Responses Re: [PATCH] Support % wildcard in extension upgrade filenames
List 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
filesby specifying less granular stopping.
 
One of the projects that will benefit from this is the PostGIS project.  Currently we ship over 300 extension scripts
perversion 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
upgradethat 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
properlyupgrade.
 

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
requestedversion, 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
newversion.
 
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
filesit 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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: heavily contended lwlocks with long wait queues scale badly
Next
From: Michael Paquier
Date:
Subject: Re: Allow file inclusion in pg_hba and pg_ident files