-
Notifications
You must be signed in to change notification settings - Fork 231
use PG_MODULE_MAGIC_EXT to report the full version #409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
On PG 18+, PG_MODULE_MAGIC_EXT allows the module to report its name and version, where the version can be more fine-grained than the SQL-level extension. So for an extension installed on a coarser version 1.6: postgres=# select extname, extversion from pg_extension where extname = 'pg_cron'; extname | extversion ---------+------------ pg_cron | 1.6 (1 row) This change allows the loaded modules to report, not only this... postgres=# select pg_get_loaded_modules(); pg_get_loaded_modules ----------------------- (,,pg_cron.so) (1 row) ...but also the bugfix release: postgres=# select pg_get_loaded_modules(); pg_get_loaded_modules ---------------------------- (pg_cron,1.6.7,pg_cron.so) (1 row) This change can help troubleshoot cases where the release is relevant and consulting the OS packages is more difficult, or where the .so might have changed without a database server restart. It does add a small amount of extra work for releases, in the sense that pg_cron.c now has to be updated along with the changelog for every release henceforth.
sandeep-edb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@tureba - As the Pull Request has been approved, could you please merge it at your earliest convenience. |
|
@tureba - We would greatly appreciate it if you could prioritize merging your PR, Because we have a upcoming release sooner. |
|
approved |
src/pg_cron.c
Outdated
|
|
||
|
|
||
| #ifdef PG_MODULE_MAGIC_EXT | ||
| PG_MODULE_MAGIC_EXT(.name = "pg_cron", .version = "1.6.7"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to use a compile constant derived from the tag. We're likely to forget updating this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fully agree.
I see some other projects pulling their versions from macros of their own headers, or the Makefile providing the macro through CFLAGS, or other mechanisms.
But I didn't find a place where the pg_cron version was kept up to date, except in CHANGELOG.md. Not sure that parsing that is the best idea.
The file META.json looks interesting, but that also looks a bit outdated.
One could ask git-decorate for the latest tag, as you mention, but that wouldn't work when building from a .tar.gz, which some distributions may be doing.
This causes make to take the latest version from the top of the CHANGELOG.md file and use it for PG_MODULE_MAGIC_EXT. This has the potential to reduce the complexity of doing new releases, by going from three places that the version needs to be synced (git tag, changelog, pg_cron.c) to two places (git tag and changelog), which already was the status quo. It does rely on the assumption that the git tag and the changelog are kept in sync for every release, which may or may not hold forever. The alternative would be to get the pg_cron version from git tag, but that'll be a problem when one is building from a .tar.gz file, which may be done by distributions nowadays.
|
@tureba please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
|
Now I pushed a new commit for the same branch that takes the version from the tip of CHANGELOG.md. I think this is an option. The other is to take the git tag, but I fear the git tag may not be available when distros build out of a .tar.gz. |
On PG 18+, PG_MODULE_MAGIC_EXT allows the module to report its name and version, where the version can be more fine-grained than the SQL-level extension.
So for an extension installed on a coarser version 1.6:
postgres=# select extname, extversion from pg_extension where extname = 'pg_cron';
extname | extversion
---------+------------
pg_cron | 1.6
(1 row)
This change allows the loaded modules to report, not only this...
postgres=# select pg_get_loaded_modules();
pg_get_loaded_modules
(,,pg_cron.so)
(1 row)
...but also the bugfix release:
postgres=# select pg_get_loaded_modules();
pg_get_loaded_modules
(pg_cron,1.6.7,pg_cron.so)
(1 row)
This change can help troubleshoot cases where the release is relevant and consulting the OS packages is more difficult, or where the .so might have changed without a database server restart.
It does add a small amount of extra work for releases, in the sense that pg_cron.c now has to be updated along with the changelog for every release henceforth.