Re: [PATCH] Support % wildcard in extension upgrade filenames
От | LEO HSU |
---|---|
Тема | Re: [PATCH] Support % wildcard in extension upgrade filenames |
Дата | |
Msg-id | 166804265261.1126.12857252111207883556.pgcf@coridan.postgresql.org обсуждение исходный текст |
Ответ на | Re: [PATCH] Support % wildcard in extension upgrade filenames (Sandro Santilli <strk@kbt.io>) |
Ответы |
Re: [PATCH] Support % wildcard in extension upgrade filenames
(Regina Obe <r@pcorp.us>)
|
Список | 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 по дате отправления:
Предыдущее
От: Andres FreundДата:
Сообщение: Re: heavily contended lwlocks with long wait queues scale badly
Следующее
От: Michael PaquierДата:
Сообщение: Re: Allow file inclusion in pg_hba and pg_ident files