Exposing PG_VERSION_NUM in pg_config

"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

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