Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Pavel Stehule]

2015-07-05 16:51 GMT+02:00 Tom Lane :

> Michael Paquier  writes:
> > On Fri, Jul 3, 2015 at 6:27 AM, Tom Lane  wrote:
> >> Michael Paquier  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


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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Andres Freund]

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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Tom Lane]

Michael Paquier  writes:
> On Fri, Jul 3, 2015 at 6:27 AM, Tom Lane  wrote:
>> Michael Paquier  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Fri, Jul 3, 2015 at 6:27 AM, Tom Lane  wrote:
> Michael Paquier  writes:
>> On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Tom Lane]

Michael Paquier  writes:
> On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Pavel Stehule]

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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Jim Nasby]

On 4/1/15 1:25 AM, Andrew Gierth wrote:

"Michael" == Michael Paquier  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Andrew Gierth]

> "Michael" == Michael Paquier  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Wed, Apr 1, 2015 at 8:50 AM, Peter Eisentraut  wrote:

> On 3/31/15 1:05 AM, Michael Paquier wrote:
> >
> >
> > On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut  > > wrote:
> >
> > On 3/30/15 6:29 PM, Michael Paquier wrote:
> > >
> > >
> > > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut  
> > > >> 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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Peter Eisentraut]

On 3/31/15 1:05 AM, Michael Paquier wrote:
> 
> 
> On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut  > wrote:
> 
> On 3/30/15 6:29 PM, Michael Paquier wrote:
> >
> >
> > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut  
> > >> 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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Wed, Apr 1, 2015 at 4:09 AM, Tom Lane  wrote:

> Michael Paquier  writes:
> > On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut 
> 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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Tom Lane]

Michael Paquier  writes:
> On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Tue, Mar 31, 2015 at 9:40 AM, Peter Eisentraut  wrote:

> On 3/30/15 6:29 PM, Michael Paquier wrote:
> >
> >
> > On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut  > > 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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Peter Eisentraut]

On 3/30/15 6:29 PM, Michael Paquier wrote:
> 
> 
> On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut  > 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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[David Fetter]

On Tue, Mar 31, 2015 at 07:29:07AM +0900, Michael Paquier wrote:
> On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut  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  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Tue, Mar 31, 2015 at 5:39 AM, Peter Eisentraut  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Peter Eisentraut]

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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Wed, Mar 25, 2015 at 2:32 PM, Michael Paquier
 wrote:
> On Wed, Mar 25, 2015 at 8:26 AM, 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.
>
> 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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Jim Nasby]

On 3/25/15 2:00 PM, Andres Freund wrote:

On 2015-03-25 14:50:44 -0400, Tom Lane wrote:

>Jim Nasby  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Andres Freund]

On 2015-03-25 14:50:44 -0400, Tom Lane wrote:
> Jim Nasby  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Tom Lane]

Jim Nasby  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Jim Nasby]

On 3/24/15 6:26 PM, Tom Lane wrote:

Andrew Gierth  writes:

"Tom" == Tom Lane  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Wed, Mar 25, 2015 at 8:26 AM, 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.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[David Fetter]

On Tue, Mar 24, 2015 at 07:26:18PM -0400, Tom Lane wrote:
> Andrew Gierth  writes:
> > "Tom" == Tom Lane  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  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Tom Lane]

Andrew Gierth  writes:
> "Tom" == Tom Lane  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Andrew Gierth]

> "Tom" == Tom Lane  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Tom Lane]

Andrew Gierth  writes:
> "Michael" == Michael Paquier  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Andrew Gierth]

> "Michael" == Michael Paquier  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

On Tue, Mar 24, 2015 at 4:06 AM, Andrew Gierth
 wrote:
>> "Michael" == Michael Paquier  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

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

[Andrew Gierth]

> "Michael" == Michael Paquier  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

[HACKERS] Exposing PG_VERSION_NUM in pg_config

[Michael Paquier]

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
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 @@
 
 
 
+ --version-num
+ 
+  
+   Print the version of PostgreSQL as a number.
+  
+ 
+
+
+
  -?
  --help
   
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(_("  --libsshow 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(_("  -?, --helpshow this help, then exit\n"));
 	printf(_("\nWith no arguments, all known items are shown.\n\n"));
 	printf(_("Report bugs to .\n"));

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers