Exposing PG_VERSION_NUM in pg_config
Hi all,
When working on extensions or packaging, one can do some grep-ing on
pg_config.h to get PG_VERSION_NUM to do version-related operations. An
example of that is the Makefile of plv8 using --include-dir with perl
and a regex:
https://github.com/plv8/plv8/blob/master/Makefile
Wouldn't it be more simple to expose PG_VERSION_NUM in pg_config with
a new option? Like that for example:
$ pg_config --version-num
90500
Attached is a patch implementing the idea.
Regards,
--
Michael
Attachments:
20150323_pgconfig_version_num.patchapplication/x-patch; name=20150323_pgconfig_version_num.patchDownload
diff --git a/doc/src/sgml/ref/pg_config-ref.sgml b/doc/src/sgml/ref/pg_config-ref.sgml
index 0210f63..6297f02 100644
--- a/doc/src/sgml/ref/pg_config-ref.sgml
+++ b/doc/src/sgml/ref/pg_config-ref.sgml
@@ -275,6 +275,15 @@
</varlistentry>
<varlistentry>
+ <term><option>--version-num</option></>
+ <listitem>
+ <para>
+ Print the version of <productname>PostgreSQL</> as a number.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-?</></term>
<term><option>--help</></term>
<listitem>
diff --git a/src/bin/pg_config/pg_config.c b/src/bin/pg_config/pg_config.c
index 9b1f95d..8b261d4 100644
--- a/src/bin/pg_config/pg_config.c
+++ b/src/bin/pg_config/pg_config.c
@@ -382,6 +382,14 @@ show_version(bool all)
printf("PostgreSQL " PG_VERSION "\n");
}
+static void
+show_version_num(bool all)
+{
+ if (all)
+ printf("VERSION_NUM = ");
+ printf("%d\n", PG_VERSION_NUM);
+}
+
/*
* Table of known information items
@@ -418,6 +426,7 @@ static const InfoItem info_items[] = {
{"--ldflags_sl", show_ldflags_sl},
{"--libs", show_libs},
{"--version", show_version},
+ {"--version-num", show_version_num},
{NULL, NULL}
};
@@ -454,6 +463,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 as a number\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"));
"Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> Hi all,
Michael> When working on extensions or packaging, one can do some
Michael> grep-ing on pg_config.h to get PG_VERSION_NUM to do
Michael> version-related operations. An example of that is the Makefile
Michael> of plv8 using --include-dir with perl and a regex:
MAJORVERSION is defined in Makefile.global as included by PGXS, fwiw.
--
Andrew (irc:RhodiumToad)
--
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, Mar 24, 2015 at 4:06 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
"Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> Hi all,
Michael> When working on extensions or packaging, one can do some
Michael> grep-ing on pg_config.h to get PG_VERSION_NUM to do
Michael> version-related operations. An example of that is the Makefile
Michael> of plv8 using --include-dir with perl and a regex:MAJORVERSION is defined in Makefile.global as included by PGXS, fwiw.
Well, my point is to have something on which you can directly apply
maths on without changing its shape ;)
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
MAJORVERSION is defined in Makefile.global as included by PGXS, fwiw.
Michael> Well, my point is to have something on which you can directly
Michael> apply maths on without changing its shape ;)
There's this trick:
# if version < 9.1 ...
ifeq ($(filter-out 7.% 8.% 9.0, $(MAJORVERSION)),)
# stuff
endif
# if version >= 9.3
ifneq ($(filter-out 7.% 8.% 9.0 9.1 9.2, $(MAJORVERSION)),)
# stuff
endif
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> Well, my point is to have something on which you can directly
Michael> apply maths on without changing its shape ;)
There's this trick:
# if version < 9.1 ...
ifeq ($(filter-out 7.% 8.% 9.0, $(MAJORVERSION)),)
# stuff
endif
# if version >= 9.3
ifneq ($(filter-out 7.% 8.% 9.0 9.1 9.2, $(MAJORVERSION)),)
# stuff
endif
That's pretty ugly :-(. I concur with Michael that there's value in
exposing the version number in the numeric form used by PG_VERSION_NUM.
However, I also concur with Andrew that if the use-case for this is
Makefiles, pg_config is a pretty poor transmission mechanism.
We should instead add PG_VERSION_NUM to the version variables set in
Makefile.global.
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
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Michael> Well, my point is to have something on which you can directly
Michael> apply maths on without changing its shape ;)
There's this trick:
# if version < 9.1 ...
ifeq ($(filter-out 7.% 8.% 9.0, $(MAJORVERSION)),)
# stuff
endif
# if version >= 9.3
ifneq ($(filter-out 7.% 8.% 9.0 9.1 9.2, $(MAJORVERSION)),)
# stuff
endif
Tom> That's pretty ugly :-(.
Yes. Though shelling out to invoke "test" is ugly in different ways,
even without using perl and regexps as well.
Tom> I concur with Michael that there's value in exposing the version
Tom> number in the numeric form used by PG_VERSION_NUM. However, I
Tom> also concur with Andrew that if the use-case for this is
Tom> Makefiles, pg_config is a pretty poor transmission mechanism. We
Tom> should instead add PG_VERSION_NUM to the version variables set in
Tom> Makefile.global.
I think there's an argument for both. pg_config already has a VERSION=
string in the output, and I think adding a VERSION_NUM= would be good
for consistency there. And people definitely do want to do version
comparisons in makefiles...
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I concur with Michael that there's value in exposing the version
Tom> number in the numeric form used by PG_VERSION_NUM. However, I
Tom> also concur with Andrew that if the use-case for this is
Tom> Makefiles, pg_config is a pretty poor transmission mechanism. We
Tom> should instead add PG_VERSION_NUM to the version variables set in
Tom> Makefile.global.
I think there's an argument for both. pg_config already has a VERSION=
string in the output, and I think adding a VERSION_NUM= would be good
for consistency there. And people definitely do want to do version
comparisons in makefiles...
Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.
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, Mar 24, 2015 at 07:26:18PM -0400, Tom Lane wrote:
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I concur with Michael that there's value in exposing the version
Tom> number in the numeric form used by PG_VERSION_NUM. However, I
Tom> also concur with Andrew that if the use-case for this is
Tom> Makefiles, pg_config is a pretty poor transmission mechanism. We
Tom> should instead add PG_VERSION_NUM to the version variables set in
Tom> Makefile.global.I think there's an argument for both. pg_config already has a VERSION=
string in the output, and I think adding a VERSION_NUM= would be good
for consistency there. And people definitely do want to do version
comparisons in makefiles...Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.
Would PG_VERSION_NUM in the Makefile actually help writers of
extensions to do numeric comparisons on the version of PostgreSQL in a
way that doesn't win a Rube Goldberg award?
If not, that's good and sufficient reason to make it a pg_config
output option.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.
Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.
Regards,
--
Michael
Attachments:
20150325_version_num_makefile.patchapplication/x-patch; name=20150325_version_num_makefile.patchDownload
diff --git a/configure b/configure
index 2c9b3a7..e5be6c7 100755
--- a/configure
+++ b/configure
@@ -627,6 +627,7 @@ ac_includes_default="\
ac_subst_vars='LTLIBOBJS
vpath_build
+PG_VERSION_NUM
PROVE
OSX
XSLTPROC
@@ -15180,6 +15181,7 @@ PG_VERSION_NUM="`echo "$PACKAGE_VERSION" | sed 's/[A-Za-z].*$//' |
tr '.' ' ' |
$AWK '{printf "%d%02d%02d", $1, $2, (NF >= 3) ? $3 : 0}'`"
+
cat >>confdefs.h <<_ACEOF
#define PG_VERSION_NUM $PG_VERSION_NUM
_ACEOF
diff --git a/configure.in b/configure.in
index b2c1ce7..c27adc1 100644
--- a/configure.in
+++ b/configure.in
@@ -1984,6 +1984,7 @@ AC_DEFINE_UNQUOTED(PG_VERSION_STR,
[PG_VERSION_NUM="`echo "$PACKAGE_VERSION" | sed 's/[A-Za-z].*$//' |
tr '.' ' ' |
$AWK '{printf "%d%02d%02d", $1, $2, (NF >= 3) ? $3 : 0}'`"]
+AC_SUBST(PG_VERSION_NUM)
AC_DEFINE_UNQUOTED(PG_VERSION_NUM, $PG_VERSION_NUM, [PostgreSQL version as a number])
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 7c39d82..659abc5 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -38,6 +38,7 @@ all:
# PostgreSQL version number
VERSION = @PACKAGE_VERSION@
MAJORVERSION = @PG_MAJORVERSION@
+VERSION_NUM = @PG_VERSION_NUM@
# Support for VPATH builds
# (PGXS VPATH support is handled separately in pgxs.mk)
On 3/24/15 6:26 PM, Tom Lane wrote:
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
"Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I concur with Michael that there's value in exposing the version
Tom> number in the numeric form used by PG_VERSION_NUM. However, I
Tom> also concur with Andrew that if the use-case for this is
Tom> Makefiles, pg_config is a pretty poor transmission mechanism. We
Tom> should instead add PG_VERSION_NUM to the version variables set in
Tom> Makefile.global.I think there's an argument for both. pg_config already has a VERSION=
string in the output, and I think adding a VERSION_NUM= would be good
for consistency there. And people definitely do want to do version
comparisons in makefiles...Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.
Why else would you want the version number other than to do some kind of
comparison? I know I've had to play these games in the past (outside of
a Makefile), though I don't remember the details right now. I'm sure I'm
not alone in that.
Michael's original patch seems to hit everything necessary but the
translations, and it's only ~15 lines. That doesn't seem very
unreasonable to me...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
On 3/24/15 6:26 PM, Tom Lane wrote:
Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.
Why else would you want the version number other than to do some kind of
comparison?
The question is why, if we supply the version number in a make variable,
you would not just use that variable instead of having to do
"$(shell $(PG_CONFIG) --something)". The shell version adds new failure
modes, removes none, and has no redeeming social value that I can see.
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 2015-03-25 14:50:44 -0400, Tom Lane wrote:
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
On 3/24/15 6:26 PM, Tom Lane wrote:
Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.Why else would you want the version number other than to do some kind of
comparison?The question is why, if we supply the version number in a make variable,
you would not just use that variable instead of having to do
"$(shell $(PG_CONFIG) --something)". The shell version adds new failure
modes, removes none, and has no redeeming social value that I can see.
I think using the makefile is preferrable if you have the version
dependency in the makefile. But if you don't actually use make
(e.g. stuff not written in C) or you need the detection in configure or
something, it's different.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3/25/15 2:00 PM, Andres Freund wrote:
On 2015-03-25 14:50:44 -0400, Tom Lane wrote:
Jim Nasby<Jim.Nasby@BlueTreble.com> writes:
On 3/24/15 6:26 PM, Tom Lane wrote:
Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.Why else would you want the version number other than to do some kind of
comparison?The question is why, if we supply the version number in a make variable,
you would not just use that variable instead of having to do
"$(shell $(PG_CONFIG) --something)". The shell version adds new failure
modes, removes none, and has no redeeming social value that I can see.I think using the makefile is preferrable if you have the version
dependency in the makefile. But if you don't actually use make
(e.g. stuff not written in C) or you need the detection in configure or
something, it's different.
Exactly; not every problem can be solved by make. I know I've had to
futz with the output of "SELECT version()" in the past, and I think I've
had to do the same with pg_config --version.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 25, 2015 at 2:32 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM
to the makefiles, but I did not hear one for adding it to pg_config; and
doing the former takes about two lines whereas adding a pg_config option
entails quite a lot of overhead (documentation, translatable help text,
yadda yadda). So I'm not in favor of doing the latter without a much
more solid case than has been made.Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.
Added entry in CF 2015-06 to not have this stuff fall into the void:
https://commitfest.postgresql.org/5/203/
--
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 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.
How would you make use of this in an extension makefile?
--
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, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.How would you make use of this in an extension makefile?
One use case is regression test list filtering depending on backend version.
--
Michael
On Tue, Mar 31, 2015 at 07:29:07AM +0900, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.How would you make use of this in an extension makefile?
One use case is regression test list filtering depending on backend version.
So basically, extension writers get to win a Rube Goldberg if they use
it for actually building software :/
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3/30/15 6:29 PM, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@gmx.net>> wrote:On 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.How would you make use of this in an extension makefile?
One use case is regression test list filtering depending on backend version.
I'm interested in the exact syntax you'd use, to compare it to the
currently used techniques.
--
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, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 3/30/15 6:29 PM, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@gmx.net>> wrote:On 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned
upthread,
and honestly I am fine as long as we do not apply maths to a
version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.How would you make use of this in an extension makefile?
One use case is regression test list filtering depending on backend
version.
I'm interested in the exact syntax you'd use, to compare it to the
currently used techniques.
With the presence of VERSION_NUM directly in pg_config, the following
expression:
VERSION_NUM=$(shell $(PG_CONFIG) --version-num)
With its presence in Makefile.global, that's close to what you can do with
pg_config.h already:
VERSION_NUM := $(shell cat `$(PG_CONFIG) --libdir`/pgxs/src/Makefile.global
\
| perl -ne 'print $$1 and exit if /VERSION_NUM =\s+(\d+)/')
But that looks a little bit magic..
Another advantage of putting this information in pg_config is for
environments that do not have PGXS installed, for example MSVC.
--
Michael
Michael Paquier <michael.paquier@gmail.com> writes:
On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
I'm interested in the exact syntax you'd use, to compare it to the
currently used techniques.
With the presence of VERSION_NUM directly in pg_config, the following
expression:
VERSION_NUM=$(shell $(PG_CONFIG) --version-num)
With its presence in Makefile.global, that's close to what you can do with
pg_config.h already:
VERSION_NUM := $(shell cat `$(PG_CONFIG) --libdir`/pgxs/src/Makefile.global
\
| perl -ne 'print $$1 and exit if /VERSION_NUM =\s+(\d+)/')
But that looks a little bit magic..
I'm confused. If PG_VERSION_NUM is defined in Makefile.global, surely
you don't need anything at all to make use of it in extension makefiles.
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 Wed, Apr 1, 2015 at 4:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net>
wrote:
I'm interested in the exact syntax you'd use, to compare it to the
currently used techniques.With the presence of VERSION_NUM directly in pg_config, the following
expression:
VERSION_NUM=$(shell $(PG_CONFIG) --version-num)With its presence in Makefile.global, that's close to what you can do
with
pg_config.h already:
VERSION_NUM := $(shell cat `$(PG_CONFIG)--libdir`/pgxs/src/Makefile.global
\
| perl -ne 'print $$1 and exit if /VERSION_NUM =\s+(\d+)/')
But that looks a little bit magic..I'm confused. If PG_VERSION_NUM is defined in Makefile.global, surely
you don't need anything at all to make use of it in extension makefiles.
No, you don't... But well, coming back to the first point: fetching it
through pg_config avoids any ugly parsing logic.
--
Michael
On 3/31/15 1:05 AM, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@gmx.net>> wrote:On 3/30/15 6:29 PM, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net <mailto:peter_e@gmx.net>
<mailto:peter_e@gmx.net <mailto:peter_e@gmx.net>>> wrote:On 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned upthread,
and honestly I am fine as long as we do not apply maths to a version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.How would you make use of this in an extension makefile?
One use case is regression test list filtering depending on backend version.
I'm interested in the exact syntax you'd use, to compare it to the
currently used techniques.With the presence of VERSION_NUM directly in pg_config, the following
expression:
VERSION_NUM=$(shell $(PG_CONFIG) --version-num)
My question is, once you have this version number in a variable like
VERSION_NUM, what specifically would you do with it?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 1, 2015 at 8:50 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 3/31/15 1:05 AM, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@gmx.net>> wrote:On 3/30/15 6:29 PM, Michael Paquier wrote:
On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <peter_e@gmx.net
<mailto:peter_e@gmx.net>
<mailto:peter_e@gmx.net <mailto:peter_e@gmx.net>>> wrote:
On 3/25/15 1:32 AM, Michael Paquier wrote:
Well, I have no other cases than ones of the type mentioned
upthread,
and honestly I am fine as long as we do not apply maths to a
version
string. So attached is a patch that adds VERSION_NUM in
Makefile.global.How would you make use of this in an extension makefile?
One use case is regression test list filtering depending on
backend version.
I'm interested in the exact syntax you'd use, to compare it to the
currently used techniques.With the presence of VERSION_NUM directly in pg_config, the following
expression:
VERSION_NUM=$(shell $(PG_CONFIG) --version-num)My question is, once you have this version number in a variable like
VERSION_NUM, what specifically would you do with it?
For an extension that has a single branch compatible with a set of multiple
major versions of Postgres, the cases are custom values for REGRESS_OPTS
and REGRESS depending on the backend version. I also manipulate on a daily
basis the same set of scripts across many platforms (on Windows as well
using msysgit, and MSVC installation does not have pgxs stuff), so I would
use it to simplify them. It is true that you can already do that by parsing
the output of "pg_config --version", and that I would need to maintain both
versions for some time (custom parsing of pg_config --version, and use of
--version-num if this patch is accepted) but it looks IMO tempting to have
directly the version number thinking long term if there is a simple integer
number available at hand to identify a given version of PG.
--
Michael
"Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> For an extension that has a single branch compatible with a
Michael> set of multiple major versions of Postgres, the cases are
Michael> custom values for REGRESS_OPTS and REGRESS depending on the
Michael> backend version. I also manipulate on a daily basis the same
Michael> set of scripts across many platforms (on Windows as well using
Michael> msysgit, and MSVC installation does not have pgxs stuff), so I
Michael> would use it to simplify them. It is true that you can already
Michael> do that by parsing the output of "pg_config --version",
What _exactly_ would you be doing that you could not already do better
with $(MAJORVERSION) which is already defined in Makefile.global?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 4/1/15 1:25 AM, Andrew Gierth wrote:
"Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> For an extension that has a single branch compatible with a
Michael> set of multiple major versions of Postgres, the cases are
Michael> custom values for REGRESS_OPTS and REGRESS depending on the
Michael> backend version. I also manipulate on a daily basis the same
Michael> set of scripts across many platforms (on Windows as well using
Michael> msysgit, and MSVC installation does not have pgxs stuff), so I
Michael> would use it to simplify them. It is true that you can already
Michael> do that by parsing the output of "pg_config --version",What _exactly_ would you be doing that you could not already do better
with $(MAJORVERSION) which is already defined in Makefile.global?
FWIW, I'm currently using this as a poor-man's version of configure, to
deal with some minor changes to function parameters between versions.
I probably would also need to screw around with regression tests but
I've given up on pretty much the whole idea of our regression
methodology and use pgTap instead. I do still run it using the built-in
framework, because of all the other stuff I get. If I had some way to
just over-ride the notion of "diff the output" I'd do that.
If I wasn't using pgTap I'm pretty sure I'd be having fun and games with
cross-version output tweaking.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Review:
1. Discussion - I read all discussion and majority opinion is positive to
this patch. I am for this patch too. I had to solve same issues with Orafce
project. More - this patch is terrible simple - it is just the publishing
already prepared value.
2. There was not any problem with patching, compilation, testing - It
should to have zero impact on PostgreSQL engine.
3. I rechecked it, and it is working
I have not any objection, so I'll mark this patch as ready for commit.
Regards
Pavel Stehule
Michael Paquier <michael.paquier@gmail.com> writes:
On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... So attached is a patch that adds VERSION_NUM in
Makefile.global.
While there was not exactly universal consensus that we need this, the
patch as given is merely two lines, so it seems awfully cheap to Just
Do It. Hence, I've gone ahead and committed it. If we start getting
complaints about use-cases this doesn't cover, we can re-discuss whether
it's worth doing more.
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 Fri, Jul 3, 2015 at 6:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
... So attached is a patch that adds VERSION_NUM in
Makefile.global.While there was not exactly universal consensus that we need this, the
patch as given is merely two lines, so it seems awfully cheap to Just
Do It. Hence, I've gone ahead and committed it. If we start getting
complaints about use-cases this doesn't cover, we can re-discuss whether
it's worth doing more.
This looks fine to me. Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
On Fri, Jul 3, 2015 at 6:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
... So attached is a patch that adds VERSION_NUM in
Makefile.global.
While there was not exactly universal consensus that we need this, the
patch as given is merely two lines, so it seems awfully cheap to Just
Do It. Hence, I've gone ahead and committed it. If we start getting
complaints about use-cases this doesn't cover, we can re-discuss whether
it's worth doing more.
This looks fine to me. Thanks.
After further thought I started wondering why I hadn't back-patched this.
It's certainly safe/trivial enough for back-patching. If we leave it just
in HEAD, then extension authors wouldn't be able to use it in the intended
way until 9.5 is old enough that they don't care about supporting 9.5.x
anymore; which is perhaps 5 years away. If we back-patch all supported
branches then it would be safe to rely on VERSION_NUM for building
extensions within a year or two.
Any objections to doing that?
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 2015-07-05 10:51:48 -0400, Tom Lane wrote:
Any objections to doing that?
Nope.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2015-07-05 16:51 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Michael Paquier <michael.paquier@gmail.com> writes:
On Fri, Jul 3, 2015 at 6:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
... So attached is a patch that adds VERSION_NUM in
Makefile.global.While there was not exactly universal consensus that we need this, the
patch as given is merely two lines, so it seems awfully cheap to Just
Do It. Hence, I've gone ahead and committed it. If we start getting
complaints about use-cases this doesn't cover, we can re-discuss whether
it's worth doing more.This looks fine to me. Thanks.
After further thought I started wondering why I hadn't back-patched this.
It's certainly safe/trivial enough for back-patching. If we leave it just
in HEAD, then extension authors wouldn't be able to use it in the intended
way until 9.5 is old enough that they don't care about supporting 9.5.x
anymore; which is perhaps 5 years away. If we back-patch all supported
branches then it would be safe to rely on VERSION_NUM for building
extensions within a year or two.Any objections to doing that?
+1
Pavel
Show quoted text
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