Thread: 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

>>>>> "Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> Hi all,Michael> When working on extensions or packaging, one can do someMichael> grep-ing on pg_config.h to
getPG_VERSION_NUM to doMichael> version-related operations. An example of that is the MakefileMichael> of plv8 using
--include-dirwith perl and a regex:
 

MAJORVERSION is defined in Makefile.global as included by PGXS, fwiw.

-- 
Andrew (irc:RhodiumToad)

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

>>>>> "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 directlyMichael> 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)

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

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Michael> Well, my point is to have something on which you can directlyMichael> 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 versionTom> number in the numeric form used by
PG_VERSION_NUM. However, ITom> also concur with Andrew that if the use-case for this isTom> Makefiles, pg_config is a
prettypoor transmission mechanism.  WeTom> should instead add PG_VERSION_NUM to the version variables set inTom>
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)

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

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

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

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

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

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

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

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?

<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Tue, Mar 31, 2015 at 5:39 AM, Peter
Eisentraut<span dir="ltr"><<a href="mailto:peter_e@gmx.net" target="_blank">peter_e@gmx.net</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On3/25/15 1:32 AM, Michael Paquier wrote:<br /> > Well, I have no other cases than ones of the type
mentionedupthread,<br /> > and honestly I am fine as long as we do not apply maths to a version<br /> > string.
Soattached is a patch that adds VERSION_NUM in<br /> > Makefile.global.<br /><br /></span>How would you make use of
thisin an extension makefile?<br /></blockquote></div><br /></div><div class="gmail_extra">One use case is regression
testlist filtering depending on backend version.<br />-- <br /><div class="gmail_signature">Michael<br
/></div></div></div>

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

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.

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

<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Apr 1, 2015 at 4:09 AM, Tom Lane
<spandir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">MichaelPaquier <<a href="mailto:michael.paquier@gmail.com">michael.paquier@gmail.com</a>> writes:<br />
>On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>>
wrote:<br/></span><span class="">>> I'm interested in the exact syntax you'd use, to compare it to the<br />
>>currently used techniques.<br /><br /> > With the presence of VERSION_NUM directly in pg_config, the
following<br/> > expression:<br /> > VERSION_NUM=$(shell $(PG_CONFIG) --version-num)<br /><br /> > With its
presencein Makefile.global, that's close to what you can do with<br /> > pg_config.h already:<br /> > VERSION_NUM
:=$(shell cat `$(PG_CONFIG) --libdir`/pgxs/src/Makefile.global<br /> > \<br /> >     | perl -ne 'print $$1 and
exitif /VERSION_NUM =\s+(\d+)/')<br /> > But that looks a little bit magic..<br /><br /></span>I'm confused.  If
PG_VERSION_NUMis defined in Makefile.global, surely<br /> you don't need anything at all to make use of it in extension
makefiles.<br/></blockquote></div><br /></div><div class="gmail_extra">No, you don't... But well, coming back to the
firstpoint: fetching it through pg_config avoids any ugly parsing logic.<br />-- <br /><div
class="gmail_signature">Michael<br/></div></div></div> 

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?

<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Apr 1, 2015 at 8:50 AM, Peter
Eisentraut<span dir="ltr"><<a href="mailto:peter_e@gmx.net" target="_blank">peter_e@gmx.net</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><spanclass="">On 3/31/15 1:05 AM, Michael Paquier wrote:<br /> ><br /> ><br />
>On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a><br
/></span><spanclass="">> <mailto:<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>>> wrote:<br />
><br/> >     On 3/30/15 6:29 PM, Michael Paquier wrote:<br /> >     ><br /> >     ><br /> >   
 >On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>
<mailto:<ahref="mailto:peter_e@gmx.net">peter_e@gmx.net</a>><br /></span><span class="">>     >
<mailto:<ahref="mailto:peter_e@gmx.net">peter_e@gmx.net</a> <mailto:<a
href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>>>>wrote:<br /> >     ><br /> >     >     On
3/25/151:32 AM, Michael Paquier wrote:<br /> >     >     > Well, I have no other cases than ones of the type
mentionedupthread,<br /> >     >     > and honestly I am fine as long as we do not apply maths to a version<br
/>>     >     > string. So attached is a patch that adds VERSION_NUM in<br /> >     >     >
Makefile.global.<br/> >     ><br /> >     >     How would you make use of this in an extension makefile?<br
/>>     ><br /> >     ><br /> >     > One use case is regression test list filtering depending on
backendversion.<br /> ><br /> >     I'm interested in the exact syntax you'd use, to compare it to the<br />
>    currently used techniques.<br /> ><br /> ><br /> > With the presence of VERSION_NUM directly in
pg_config,the following<br /> > expression:<br /> > VERSION_NUM=$(shell $(PG_CONFIG) --version-num)<br /><br
/></span>Myquestion is, once you have this version number in a variable like<br /> VERSION_NUM, what specifically would
youdo with it?<br /></blockquote></div><br /></div><div class="gmail_extra">For an extension that has a single branch
compatiblewith a set of multiple major versions of Postgres, the cases are custom values for REGRESS_OPTS and REGRESS
dependingon the backend version. I also manipulate on a daily basis the same set of scripts across many platforms (on
Windowsas well using msysgit, and MSVC installation does not have pgxs stuff), so I would use it to simplify them. It
istrue that you can already do that by parsing the output of "pg_config --version", and that I would need to maintain
bothversions for some time (custom parsing of pg_config --version, and use of --version-num if this patch is accepted)
butit looks IMO tempting to have directly the version number thinking long term if there is a simple integer number
availableat hand to identify a given version of PG.<br /></div><div class="gmail_extra">-- <br /><div
class="gmail_signature">Michael<br/></div></div></div> 

>>>>> "Michael" == Michael Paquier <michael.paquier@gmail.com> writes:
Michael> For an extension that has a single branch compatible with aMichael> set of multiple major versions of
Postgres,the cases areMichael> custom values for REGRESS_OPTS and REGRESS depending on theMichael> backend version. I
alsomanipulate on a daily basis the sameMichael> set of scripts across many platforms (on Windows as well usingMichael>
msysgit,and MSVC installation does not have pgxs stuff), so IMichael> would use it to simplify them. It is true that
youcan alreadyMichael> 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)

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

<div dir="ltr"><br /><div class="gmail_extra">Review:<br /><br /></div><div class="gmail_extra">1. Discussion - I read
alldiscussion and majority opinion is positive to this patch. I am for this patch too. I had to solve same issues with
Orafceproject. More - this patch is terrible simple - it is just the  publishing already prepared value. <br
/></div><divclass="gmail_extra"><br /></div><div class="gmail_extra">2. There was not any problem with patching,
compilation,testing - It should to have zero impact on PostgreSQL engine.<br /><br /></div><div class="gmail_extra">3.
Irechecked it, and it is working<br /></div><div class="gmail_extra"><br /></div><div class="gmail_extra">I have not
anyobjection, so I'll mark this patch as ready for commit.<br /></div><div class="gmail_extra"><br /></div><div
class="gmail_extra">Regards<br/><br /></div><div class="gmail_extra">Pavel Stehule<br /></div></div> 

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

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

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

On 2015-07-05 10:51:48 -0400, Tom Lane wrote:
> Any objections to doing that?

Nope.