pg_config --version-num
Hi all
Attached is a small patch to teach pg_config how to output a --version-num
With Pg 10, parsing versions got more annoying. Especially with
"10beta1", "9.6beta2" etc into the mix. It makes no sense to force
tools and scripts to do this when we can just expose a sensible
pre-formatted one at no cost to us.
Personally I'd like to backpatch this into supported back branches,
but just having it in pg 10 would be a help.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
v1-0001-Provide-numeric-version-from-pg_config.patchtext/x-patch; charset=US-ASCII; name=v1-0001-Provide-numeric-version-from-pg_config.patchDownload
From 87647fab7f8ce607de4cfc098cd9a8519149bc31 Mon Sep 17 00:00:00 2001
From: Craig Ringer <craig@2ndquadrant.com>
Date: Wed, 31 May 2017 09:10:33 +0800
Subject: [PATCH v1] Provide numeric version from pg_config
Add pg_config --version-num to print integer version, for scripts/tools
---
src/bin/pg_config/pg_config.c | 2 ++
src/common/config_info.c | 6 +++++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_config/pg_config.c b/src/bin/pg_config/pg_config.c
index fa2a5a9..3e576fa 100644
--- a/src/bin/pg_config/pg_config.c
+++ b/src/bin/pg_config/pg_config.c
@@ -64,6 +64,7 @@ static const InfoItem info_items[] = {
{"--ldflags_sl", "LDFLAGS_SL"},
{"--libs", "LIBS"},
{"--version", "VERSION"},
+ {"--version-num", "VERSION_NUM"},
{NULL, NULL}
};
@@ -100,6 +101,7 @@ help(void)
printf(_(" --ldflags_sl show LDFLAGS_SL value used when PostgreSQL was built\n"));
printf(_(" --libs show LIBS value used when PostgreSQL was built\n"));
printf(_(" --version show the PostgreSQL version\n"));
+ printf(_(" --version-num show the PostgreSQL version in integer form\n"));
printf(_(" -?, --help show this help, then exit\n"));
printf(_("\nWith no arguments, all known items are shown.\n\n"));
printf(_("Report bugs to <pgsql-bugs@postgresql.org>.\n"));
diff --git a/src/common/config_info.c b/src/common/config_info.c
index ad506be..e056f91 100644
--- a/src/common/config_info.c
+++ b/src/common/config_info.c
@@ -39,7 +39,7 @@ get_configdata(const char *my_exec_path, size_t *configdata_len)
int i = 0;
/* Adjust this to match the number of items filled below */
- *configdata_len = 23;
+ *configdata_len = 24;
configdata = (ConfigData *) palloc(*configdata_len * sizeof(ConfigData));
configdata[i].name = pstrdup("BINDIR");
@@ -200,6 +200,10 @@ get_configdata(const char *my_exec_path, size_t *configdata_len)
configdata[i].setting = pstrdup("PostgreSQL " PG_VERSION);
i++;
+ configdata[i].name = pstrdup("VERSION_NUM");
+ configdata[i].setting = pstrdup(CppAsString2(PG_VERSION_NUM));
+ i++;
+
Assert(i == *configdata_len);
return configdata;
--
2.9.4
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
Attached is a small patch to teach pg_config how to output a --version-num
With Pg 10, parsing versions got more annoying. Especially with
"10beta1", "9.6beta2" etc into the mix. It makes no sense to force
tools and scripts to do this when we can just expose a sensible
pre-formatted one at no cost to us.Personally I'd like to backpatch this into supported back branches,
but just having it in pg 10 would be a help.
The last threads treating about the same subject are here:
/messages/by-id/CAB7nPqTAdAJpX8iK4V3uYJbO2Kmo8rHzqJKDsLaDdranNrGX_A@mail.gmail.com
/messages/by-id/20161127001648.GA21874@fetter.org
Is the data in Makefile.global unsufficient?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 31 May 2017 9:36 am, "Michael Paquier" <michael.paquier@gmail.com> wrote:
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
Attached is a small patch to teach pg_config how to output a --version-num
With Pg 10, parsing versions got more annoying. Especially with
"10beta1", "9.6beta2" etc into the mix. It makes no sense to force
tools and scripts to do this when we can just expose a sensible
pre-formatted one at no cost to us.Personally I'd like to backpatch this into supported back branches,
but just having it in pg 10 would be a help.
The last threads treating about the same subject are here:
/messages/by-id/CAB7nPqTAdAJpX8iK4V3uYJbO2Kmo8
rHzqJKDsLaDdranNrGX_A@mail.gmail.com
/messages/by-id/20161127001648.GA21874@fetter.org
Is the data in Makefile.global unsufficient?
It's a pain in the butt because then you need to find or get passed the
name of Makefile.global. Then you have to template it out into a file. Or
parse the Makefile. Or create a wrapper program to emit it.
It's beyond me why we don't expose this at runtime for use in scripts and
tools. (Then again, the same is true of reporting it in the startup message
and we know how that's gone).
Craig Ringer <craig@2ndquadrant.com> writes:
On 31 May 2017 9:36 am, "Michael Paquier" <michael.paquier@gmail.com> wrote:
Is the data in Makefile.global unsufficient?
It's a pain in the butt because then you need to find or get passed the
name of Makefile.global. Then you have to template it out into a file. Or
parse the Makefile. Or create a wrapper program to emit it.
It's beyond me why we don't expose this at runtime for use in scripts and
tools. (Then again, the same is true of reporting it in the startup message
and we know how that's gone).
Hm, but with this you're trading that problem for "is the right version
of pg_config in my PATH?". I can't see using this in TAP testing, for
instance, because it would never work in "make check" scenarios.
This idea might well be useful for external packages which are always
built/tested against installed versions of Postgres. But it seems like
we need to think harder about what to do for our own usages, and that
may lead to a different solution altogether.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, May 30, 2017 at 6:36 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Tue, May 30, 2017 at 6:14 PM, Craig Ringer <craig@2ndquadrant.com>
wrote:Attached is a small patch to teach pg_config how to output a
--version-num
With Pg 10, parsing versions got more annoying. Especially with
"10beta1", "9.6beta2" etc into the mix. It makes no sense to force
tools and scripts to do this when we can just expose a sensible
pre-formatted one at no cost to us.Personally I'd like to backpatch this into supported back branches,
but just having it in pg 10 would be a help.The last threads treating about the same subject are here:
/messages/by-id/CAB7nPqTAdAJpX8iK4V3uYJbO2Kmo8
rHzqJKDsLaDdranNrGX_A@mail.gmail.com
Tom's comment here:
"whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda)."
The proposed doesn't touch the first item and patch author's aren't
expected to handle the second. Not sure what all the rest entails...but I
cannot imagine it is a considerable amount of stuff that amounts to little
more than boilerplate text paralleling what is already out there for the
existing --version option. If someone is willing to do that I'd think we
should feel OK with the little bit of translation would that would need to
occur because of it.
The fact that this is even on the radar means that more than likely there
are sensible uses for this capability whether they've been adequately
presented or not. We don't have someone begging for help here but rather
ultimately a complete patch that can be committed and which would require
pretty much zero maintenance.
While I don't do it presently I could very well imagine value in being able
to inspect installed versions PostgreSQL, including patch levels, without
needing a running server process or the ability to login.
David J.
On Tue, May 30, 2017 at 8:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm, but with this you're trading that problem for "is the right version
of pg_config in my PATH?".
That is probably a solved problem for those who are parsing the output of
--version today.
This idea might well be useful for external packages which are always
built/tested against installed versions of Postgres. But it seems like
we need to think harder about what to do for our own usages, and that
may lead to a different solution altogether.
While we may not want to go to the extreme that is Perl, there being more
than one way to do things does have merit. Given that we run 5 concurrent
releases of our software and put out new ones annually the version is a
very important piece of information. There being 5 different ways to get
at that data is not inherently bad since each way likely is most useful to
different subsets of our users. To allow people to scratch their own itch,
here specifically, seems like an easy win in making the project visibly
responsive to the community.
David J.