From 5b1e2fd25a21cfd9e22f6bf077180664a0c0e55c Mon Sep 17 00:00:00 2001
From: Arthur Nascimento <arthur.nascimento@enterprisedb.com>
Date: Fri, 10 Oct 2025 15:08:05 -0300
Subject: [PATCH 1/2] use PG_MODULE_MAGIC_EXT to report the full version

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.
---
 src/pg_cron.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/pg_cron.c b/src/pg_cron.c
index e202d14..7d35052 100644
--- a/src/pg_cron.c
+++ b/src/pg_cron.c
@@ -94,7 +94,11 @@
 #include "utils/builtins.h"
 
 
+#ifdef PG_MODULE_MAGIC_EXT
+PG_MODULE_MAGIC_EXT(.name = "pg_cron", .version = "1.6.7");
+#else
 PG_MODULE_MAGIC;
+#endif
 
 #ifndef MAXINT8LEN
 #define MAXINT8LEN 20

From 8f4c074317846e49ba0cb2b048fc7e34d9b45f3b Mon Sep 17 00:00:00 2001
From: Arthur Nascimento <arthur.nascimento@enterprisedb.com>
Date: Fri, 19 Dec 2025 11:00:49 -0300
Subject: [PATCH 2/2] PG_MODULE_MAGIC_EXT: use version from CHANGELOG.md

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.
---
 Makefile      | 1 +
 src/pg_cron.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index c139cac..3892367 100644
--- a/Makefile
+++ b/Makefile
@@ -19,6 +19,7 @@ endif
 ifeq ($(shell uname -s),SunOS)
     PG_CPPFLAGS += -Wno-sign-compare -D__EXTENSIONS__
 endif
+PG_CPPFLAGS += -DPG_CRON_VERSION=$(shell sed -r -n -e '1s/.* v([^ ]*) .*/\1/p' <CHANGELOG.md)
 SHLIB_LINK = $(libpq)
 EXTRA_CLEAN += $(addprefix src/,*.gcno *.gcda) # clean up after profiling runs
 
diff --git a/src/pg_cron.c b/src/pg_cron.c
index 7d35052..1c9683a 100644
--- a/src/pg_cron.c
+++ b/src/pg_cron.c
@@ -95,7 +95,7 @@
 
 
 #ifdef PG_MODULE_MAGIC_EXT
-PG_MODULE_MAGIC_EXT(.name = "pg_cron", .version = "1.6.7");
+PG_MODULE_MAGIC_EXT(.name = "pg_cron", .version = PG_CRON_VERSION);
 #else
 PG_MODULE_MAGIC;
 #endif